[mrtg] MRTG and bandwidth delay product
jay at west.net
Wed Dec 31 07:18:03 CET 2008
nangineni praneeth wrote:
> Hello everyone....
> I am working in a lab environment...This is how configured my network.....
> I designed a enterprise campus network which operates at 100mbps...The
> enteprise edge router in the enterprise campus network connects to the
> branch office router using a frame relay connection. The frame relay PVC
> operates at 8kB/s...The clients in the branch office connect to the
> branch office router with links operating at 100mbps...I have setup a
> filezilla ftp server in the enterprise campus network and limited the
> speed at which it can send the data to the clients at 4kB/s....
> So i am calcuting the rtt with MRTG and monitoring network with
> MRTG....MRTG calculated the max round trip time to 340ms..between the
> client in the branch office and the server in the enterprise campus
> network.....I wanted to theoritically prove that the link cannot carry
> more than x bytes of data or in other words because of certain latency
> the effective bandwidth of the link is limited to only xbytes/second...I
> used bandwidth delay product to do this......
> So this is saying that the effective throughput of the link with a
> latency of 340 ms is 2.72kB/s......But when i am using MRTG to graph
> bandwidth the max bandwidth it was showing was 4kBps which is what we
> should expect...
> My question is how can i theoritically prove that the effective
> throughput of the link is xbytes per second ..I think i am
> misunderstanding the bandwidth delay product.....Can anyone correct me
> if i am wrong....
Your delay is almost 100% serialization delay of stringing the bits on
the wire, as opposed to propagation delay where you have a high
bandwidth circuit (by definition low serialization delay) traveling over
a long distance resulting in speed-of-light delay. In effect, your
measurement of delay delay is a result of low bandwidth in assembling a
packet, not delay independent of serializing the data on the wire.
Because the propagation delay is minimal, you don't have several packets
in transit waiting on TCP acknowledgment and therefore you won't have a
A better lab demonstration would be to have a high-bandwidth link such
as your 100Mbps ethernet, and introduce latency (delay) with a
simulator. Google for "netem" and "nistnet" for suitable programs.
Low bandwidth, low latency (serialization delay):
You have a very short section of railroad track. A 1500-car freight
train is moving very slowly. You start timing when the engine leaves
the starting point, and you stop timing when the last car crosses your
location five feet from the start. It takes an hour.
High bandwidth, high latency (propagation delay):
A very high speed rail track stretches across the country. It takes
less than a minute between when the engine and the last car of a
1500-car train crosses a given point. The track is many miles long and
many trains can fit on it one-after-the other. However, it takes an
hour for a train to traverse the length of the track.
In both scenarios, it takes one hour for the first 1500-car "packet" to
cross the wire. But in the second scenario many more packets per hour
can be delivered once the first one arrives if the track is used
TCP windowing and BDP have to do with the sending end holding up trains
waiting for confirmation from the receiving end that there isn't a train
wreck in the middle. If the sending end waits for confirmation that
each and every train has arrived safely before sending the next, then
the long track will be mostly empty waiting on the one-hour it takes for
the sending end to get the OK from the receiving end once each train
arrives. If the sending end sends fifty trains before waiting for word
that the first has arrived safely, then throughput improves.
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service - http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
More information about the mrtg