Network Measurement Bandwidth Analysis Why measure bandwidth n

Network Measurement Bandwidth Analysis

Why measure bandwidth? n n n Network congestion has increased tremendously. Bottlenecks are not always obvious. Measuring bandwidth may become more essential for service providers as congestion increases. Measuring bandwidth enables us to improve current systems as well as diagnosis network problems. Measuring bandwidth may be the key to observing what is wrong with current protocol standards. In effect, measurement is a tool for research in general.

How we measure bandwidth It’s really more complicated than a connection speed. n We might want to look at capacity or we might be looking at n throughput or bandwidth congestion. n n We can observe packet loss, propagation delay, link capacity, but some of this results in educated “guess work. ” There are many theories and applications intended to measure bandwidth and network statistics. For our purposes we will look at the three most common utilities used: traceroute, ping, and pathchar. It really depends on what you are after!

traceroute n n Written by Van Jacobsen in 1988 to solve persistent network problems. Traceroute counts hops : roughly tracing the path of an IP packet from the client to the destination. Traceroute does this by sending UDP packets with an extremely short TTL. If all routing nodes in the path are working properly, an ICMP (Internet Connection Message Protocol) Time Exceeded message is sent (RFC 792).

traceroute Traceroute utilizes the information encapsulated in the ICMP message to determine the source (the router that sent the packet). n We continue sending packets until we get an ICMP “host unreachable message” (this implies that we have reached the destination) or until the max number of hops has been reached. n

traceroute disadvantages Traceroute is a simple tool that is based on a few key ideas: 1. All packets will be sent on the same paths (going). 2. Consistent Routing (all packets will be routed back the same way). 3. TCP/IP implementations supporting ICMP. In reality, poor TCP/IP implmentation means that Traceroute is not dependable. Using three different Traceroute implementations, to the same IP address, resulted in three different routes.

ping One of the most widely distributed analysis tools. First released in 1980. n The UNIX version of ping is slightly more robust, allowing us to specify the testing data and modify the patterns. n ping, works by sending a single packet and waiting for the ICMP Echo response. n

ping n n ping puts its own Round Trip Time value on each packet so we are not left at the mercies of the router (as in traceroute). ping also provides us with a diagnostic of ICMP messages, usually buried by the system. ping is clearly a much different tool from traceroute, but it’s simplicity makes it more reliable. ping is only useful for estimating bandwidth under certain conditions.

Pathchar n n n Also written by Van Jacobson, in 1997. pathchar attempts to improve upon traceroute by adding mathematical analysis to the problems that occur in propagation. Working in the same basic manner as traceroute, pathchar sends out packets and waits for the response. Only instead of one set of packets, it sends out several. The difference being the analysis of the returned data. pathchar attempts to account for: - loss rate - link capacity - propagation and queing delay (Grossglauser, pg 40)

Taking into account the rtt from two nodes, say n and n – 1 we generate the following formula using Van Jacobson’s specifications: pathchar But he assumes three things: n n n The error message is small enough to ignore (toss error_size/bandwidth out) The forward time is not big enough to worry about. If enough transmission groups are sent at least one will not have any queuing delays. And so, we get:

pathchar n In practice pathchar is not the easiest tool to use. It can be difficult to implement and its output is often chaotic. n n A better implementation of pathchar was made by Bruce Mah, called pchar Here is an example of a particular node in a trace.

What we learn from pathchar n n n Pathchar’s focus is on the statistics of data loss and the analysis of delay. Instead of capacity, we can look at data loss and latency. Using pathchar and traceroute, one is more likely to track down the source of delay than to estimate bandwidth in the sense of capacity. In a commercial sense, we can utilize this information to see where end users are running into difficulty. In private application weak network components can be sorted out. For our purposes, bandwidth congestion allows us to think intelligibly about improving network protocols and gives us some real world metric to diagnosis real world problems.

Conclusion There are two things we can conclude from this: n ICMP may need to be rewritten to facilitate better tools. n Bandwidth Analysis is at it’s heart a simple idea. n

Sources Downey, Alan B. “Using pathchar to estimate Internet length characteristics. ” http: //www. acm. org/sigcomm 99/papers/session 7 -1. pdf. 1999 Jacobson, Van. “pathchar – A Tool to Infer Characteristics of Internet Paths. ” ftp: //ftp. ee. lbl. gov/pathchar/msri-talk. pdf. April 21, 1997. Postel, J. “RFC 792 Internet Control Message Protocol. ” http: //www. freesoft. org/CIE/RFC/792/index. htm. September, 1981.