Transcript Network Measurement: Bandwidth Analysis

Network Measurement
Bandwidth Analysis
Why measure bandwidth?





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.
We might want to look at capacity or we might be looking at
throughput or bandwidth congestion.




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




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).
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.
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.
 The UNIX version of ping is
slightly more robust, allowing us
to specify the testing data and
modify the patterns.
 ping, works by sending a single
packet and waiting for the ICMP
Echo response.

ping




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





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, pg40)
pathchar
Taking into account the rtt from two nodes, say n and n – 1 we generate the
following formula using Van Jacobson’s specifications:
But he assumes three things:



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

In practice pathchar is not the easiest tool to use. It can be difficult to
implement and its output is often chaotic.


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






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:
ICMP may need to be rewritten to facilitate better tools.
Bandwidth Analysis is at it’s heart a simple idea.
Sources
Downey, Alan B. “Using pathchar to estimate Internet length
characteristics.”
http://www.acm.org/sigcomm/sigcomm99/papers/session7-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.