[mrtg] MRTG and bandwidth delay product

[Lyle Giese]

nangineni praneeth wrote:
> Thanks for your reply.I studied in various books and web articles that
> the throughput of a link is limited by Round trip time. Actually the
> product which i was speaking about earlier is also referred to as TCP 
> receive window size  which is the maximum amount of received data, in
> bytes, that can be buffered at one time on the receiving side of a
> connection. The sending host can send only that amount of data before
> waiting for an acknowledgment .
>
> The link below explains it in much more detail
> http://www.speedguide.net/faq_in_q.php?category=89&qid=185
>
> I would be glad if anyone could show me a way which would let me prove
> that by limiting the  ftp server to send data at constant rates i am
> able to operate the network efficiently
>
> For eg: I am limiting the server to send traffic at 4kBps hence the
> effective throughput is xB/s and the effecting throughput of the
> network is yB/s when the server is sending the traffic at 8kB/s and so
> on.....
>
> Regards
> Venkat
>
>
> --- On *Wed, 12/31/08, Lyle Giese /<lyle at lcrcomputer.net>/* wrote:
>
>     From: Lyle Giese <lyle at lcrcomputer.net>
>     Subject: Re: [mrtg] MRTG and bandwidth delay product
>     To: nv_2030 at yahoo.com
>     Cc: mrtg at lists.oetiker.ch
>     Date: Wednesday, December 31, 2008, 8:37 AM
>
>     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.
>
>
>
>
Ok, at the TCP packet level is where the acknowledgements are done.  Now
in their article you have to have a enough throughput so that the acks
being sent back are not getting back fast enough, so that the sender has
to wait for acknowledgements.  You need to calculate how long it takes
to send a TCP packet over your line.  You have to enough bandwidth to
send three or more packets before the acknowledgement for the first
packet is received by the sender.

I don't think 8kilobytes/second is fast enough to meet that criteria, in
order for their formula to engage.

Lyle

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