When you experience a slow or inconsistent Internet connection it is often difficult to gather the needed information and determine the problem, but the answer is easier than you may think.

Computer networks are by design contention based networks. This means a network is shared by many and all network traffic for the many has to somehow contend to survive. The majority of the problems experienced by home users and indeed many corporate network users fall into two distinct camps. The first and the most common is congestion. The second, and hardest to prove, is regulation.

The congestion problem is simply that. The ISP network that you use has too much network traffic and this causes inherent delays to your data packets. This is synonymous with public roads in rush hour, when too much traffic at peak times causes excessive delays. The solution is simple: do not drive in the rush hour unless you have to if you want to avoid those delays.

The regulation problem is a natural counter to the congestion issue and again this parallels public road use in the real world. ISPs intentionally regulate your network traffic flow in order to provide a balance for all the other network users that share your connection to the Internet. For the public roads, traffic authorities create regulation methods which, similar to network traffic, are designed to keep the traffic flowing when congested, traffic lights are a good example.

Are you getting the connection speed you pay for? And if not, what should you do to prove this?

The first step in answering this question is to ascertain the bandwidth speeds you are experiencing. This requires that you run a connection speed test to measure bandwidth throughput, it is then simply a matter of deciding if the service received matches the service contracted. Running a speed test is the process of sending (upload) and receiving (download) a fairly large amount of uncompressible¹ data and timing how long the data takes to arrive.

For example, if 1 megabyte of data sent in 10 seconds is:

1,000,000*8 / 10 = 0.8 megabits per second (Mbps)

and your contracted service was for 1.0 Mbps then you might accept this as a measure that is close enough. However if your service is meant to be 5 Mbps then your actual speed performance is far less than you should be getting.

The speed test in Fig. 1 shows a download speed of 1.13 Mbps, however the connection this test originated on was contracted at 4.5 Mbps. Assuming you were not using the network at the time of the test was initiated, this is not a good result by any account.

The essence of the solution is to make an assessment of the problem and then present your case with supporting evidence to your ISP.

¹ Many speed tests on the internet are inherently inaccurate because they download an image file or similar which the hardware compresses. This can mean that 40% or more of the data volume is not actually sent.

The first step in the resolution process is to perform a series of bandwidth speed tests, as a single speed test can be skewed and does not provide representative sample on which to base a complaint. To do this you should take a number of speed tests over a representative period of time at set intervals, such as every 20 minutes for a couple days. A series of tests provides a better picture of network performance and helps identify patterns, such as lower speeds during prime time or rush hour, and makes for a more credible report to provide to your ISP.

It is important that you analyze the data with the purpose of identifying your assessment of the root cause. Taking this extra step does two things to help your case. Firstly it helps the remote support technician to grasp the extent of your problem more quickly, and secondly it helps you to get acceptance of the problem by the ISP. Acceptance of the problem is singularly the most important aspect of getting the problem resolved.

Proving congestion is relatively straightforward but can require collecting a good amount of speed test data. The amount of data is usually needed because network congestion, just like the rush hour traffic, occurs in cyclical time phases. Showing a clear time phase correlation is powerful proof that the ISPs network is congested.

Fig. 2 – Congestion patterns - day versus night

For example the Fig. 2 graph above shows a number of speed tests extracted from the MyConnection Server Server database for a single user connection. This data shows a clear drop in service during daytime hours, which then improves towards evening and returns to normal during the night. This type of pattern is typical of congestion, and would be an issue for your ISP to address.

It is also possible to get a clue that congestion is the issue before you go to the length of collecting significant amounts of data over several days. Signs of congestion can often be seen when conducting initial speed tests -- MyConnection Server analyzes the data flow during the test, the data flow graphs provide visibility to quality of your connection service.

   
Fig. 3 - Congestion signs versus good quality service

In Fig. 3 above both tests had almost the same throughput, however the left graph shows an erratic test, a strong sign of congestion, whereas the right graph shows a test that is much more consistent, a strong sign of good quality service. Note that even in the case of a good quality test, if the actual speed was too slow it would likely mean that the throughput was limited by design, i.e. some intentional traffic control.

It is common to find Internet connections where traffic is regulated. Several factors drive this necessity. First it is common for users to be connected to a network which is much faster than the speed they have contracted. In other words, if you have contracted a 10 Mbps service, instead of having a dedicated 10 Mbps connection you actually have one tenth of a 100 Mbps connection. Second, there needs to be a method to adjust data flow based on data volume, not data speed. This is to prevent any single user from consuming all of the available capacity and is common on cable connections where several users share a common piece of wire.

To understand traffic control issues we need to plot the traffic patterns in more detail and include the inherent delays recorded during the connection test with the speed related data. In our public road scenario, this is a bit like watching the traffic lights at a busy road junction to plot red time versus green time as it relates to the traffic volume.

Fig. 4 - Traffic delays at regular intervals

In the Fig. 4 chart above we see two bandwidth measures plotted over time. The first is data (traffic) speed shown in blue and the second is data (traffic) delay shown in red. In a congestion situation the delays have no notable pattern -- there might be many small delays, a number of large delays or a mixture of both, all totally random in regards to the timing of the delays. In a traffic control environment we see the opposite, a regular pattern of delays throughout the test. This would be similar to the traffic lights on a busy road intersection, a pattern of stop/go would emerge based on the timing of the lights.

Fig. 4 shows 4 red line columns indicating a 200 ms delay precisely every 2000 ms. This is hardly congestion as it is far too precise an interval to be random. This is indicative of a connection that is being intentionally policed. If you look closely at the blue data line you will see that data flow drops like a stone at the time of the delay but jumps high after the delay has passed. This is not unlike a train service such as the New York subway at 9 am on a Monday morning. If trains run frequently then, assuming passengers are arriving at a fairly constant rate, when the next train arrives the same number of passengers will board. If there is a long delay between trains then the next train to arrive after the delay will find many more passengers waiting to board and a spike in throughput will be seen.

The next time you find yourself fighting network delays that you want to pass to your ISP for resolution, take a moment to gather the performance data so you can better ascertain the extent and scope of the problem you are experiencing. Just telling the ISP that your connection is slow is of little use. By taking a few extra hours or days to gather the data will better identify whether the delays are traffic congestion or traffic control related, and will help your ISP respond more quickly and resolve the issues.