Don’t blame the network – ask the network!
2026-07-21 , Room 1

When systems have problems often times engineers say it is a network problem… and they’ll say this without any actual data pointing the finger at the network. Sometimes it is a blamestorming session – database group is blaming the network, network is blaming the software, software is blaming the hardware speed, and hardware is blaming the database.

When this happens, the best thing to do is kick everyone out of the room, sniff the data, and see where/what the bottleneck is. More often than not it isn’t one particular thing but the interactions between two endpoints that just don’t completely like each other. Identifying that is the first step in getting the right groups talking to each other and resolving the root of the issue.

In this talk I’ll setup N real world scenarios, describe the problem, show the captured data and how if you ask the capture in the right way how the problem will reveal itself.

I'm a geek and not afraid to wear my propeller hat in public. Started programming at age 12 (1976) taking a community college course on Fortran IV programming punching cards and found I just 'got it' ... to the point I was spending a lot of time helping the other "kids" in the course with their machine problems. At one point I asked my professor "Do they actually pay people to do this?" to which he replied "Oh yes!"... "I'm going to do this for the rest of my life!" and have.