[mrtg] MRTG and bandwidth delay product

[Jay Hennigan]

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......
> 
> BDP=0.340*8kBps=2.72kB/s
> 
> 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 
windowing problem.

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 
effectively.

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