[mrtg] MRTG and bandwidth delay product

[Lyle Giese]

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....
>
> I wish you all a good new year ahead..
> Regards
> Venkat
>
Delay has a heavy effect on a stop-start transfer protocol like Xmodem
or Ymodem.  But for streaming protocols(FTP is a streaming protocol),
delay has a minimal effect on throughput. 

Limiting FTP to 4k over an 8k line, you are going to get close to the 4k
max in practice, because bandwidth is not a limiting factor.  FTP is a
streaming protocol and depends on the TCP protocol to ensure that what
is being sent is what will be received and there is no acknowledgement
sent back by the sender for each packet(as Xmodem or Ymodem did over
dialup) unless there is a transmission error.  Since there is no acks
required by the sender, there is no delay in waiting for those acks.

So I am wondering why you think transmission delay would introduce a
reduction in speed, since the sender is not waiting for any responses on
a per packet basis from the receiver?  I could see that in a protocol
like Xmodem, Ymodem or Zmodem where per packet acks needed to be
returned to the sender.

Lyle Giese
LCR Computer Services, Inc.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20081230/d05fcc5c/attachment.html