There are frequent occasions where the line status and test history results on the BroadBandreports web site can be a bit misleading. This is because the tests make some generic assumptions about the results they receive, and then provide you with some limited insight on where a problem may exist. (You can see that this limited insight approach is confirmed on the test results page in the phrase near the bottom that states, "This is just one test, over one short time. Results shown here need to be added to what you know to be the problems [if any] on your link .") Simply translated, this means this was a snapshot of a single moment in time from a very specific angle.

That said, the tests are a pretty good diagnostic start. I want to expand on the feedback the tests return and perhaps help you get a little closer to the root cause of the problem.

To begin with, most data that you send and receive over the Internet is one of two varieties of IP data: either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). TCP is a reliable delivery protocol requiring confirmation from the receiving end that each packet is received (end to end acknowledgements). In other words, it's a reliable service in the manner that it provides mechanisms for timeouts and retransmissions. UDP is a best effort, whereby the source sends the data and hopes for the best. It does NOT require delivery receipt confirmation. Streaming media such as video and audio often use the UDP protocol.

Most of the routers on the Internet are optimized for the routing, handling, and transmission of this TCP/IP and UDP/IP data. However, many of the diagnostic tools such as ping and traceroute use a different protocol called Internet Control Message Protocol (ICMP). Consequently, most routers on the Internet are not optimized for handling ICMP/IP data. This is particularly true when the ICMP packet is destined for the actual routers itself versus simply passing through the router. Because of this, routers will often purposely deprioritize -- or in extreme cases ignore -- ICMP data thus giving the impression the packet has either been hung up or lost because of a router’s failure. Additionally some sites and whole networks will filter ICMP traffic at the border. It is important to analyze the results of the line status test results with this in mind. For a more detailed explanation, click here.

As an example, take a look at the test results to the right. This test indicates () that the test failed. This is based on the fact that at different parts of the path packet loss of 9%, 10%, and 12% was observed. However, notice in the top table (East Coast - uunet to YOU), packet loss to the customer was actually 0%!! In this case the tool is falsely interpreting the results. Could the packet loss be a problem? Yes, possibly it's a warning sign that the router may not be optimized or properly configured. In Cox's case, some of our routers are known to not respond to ICMP queries very efficiently. Nevertheless, if the end result is little or no packet loss to the end point, then the path is ok.

Another challenge in using the line status test is it is inbound towards the customer instead of outbound from the customer. Now, there is a lot of value with this type of view. It can turn up issues that the customer would never be able to see with tools looking outbound from their computer, but it also relies on ICMP responses from the customer's home. Where Internet routers and web servers are built to deal with ICMP requests in some fashion, the wide variety of equipment in a customer's home (PC's, home gateways, etc.) often doesn’t respond well to ICMP requests. 2-4% packet loss is very common with this test and even the DSLR report will call 2% packet loss a Pass ( ).

This web page is work in progress. As I see other examples of issues I will come back and update and augment

(back)