<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Thank a ton for your explanation..Without knowing this stuff i spent quite a bit of time working on BDP trying to prove theoritically the effective throughput of a link..Of course in vague because of the reasons you gave....Anyways i can use this formula when trying to work on long fat networks with delay in it....I had a look into nistnet FAQ as well. They have given a reasonable explanation on different round trip times related to varying ping packet sizes which i will be looking into....<br><br>Regards<br>Venkat<br><br><br><br><br>--- On <b>Wed, 12/31/08, Lyle Giese <i><lyle@lcrcomputer.net></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Lyle Giese <lyle@lcrcomputer.net><br>Subject: Re: [mrtg] MRTG and bandwidth delay product<br>To: nv_2030@yahoo.com<br>Cc:
mrtg@lists.oetiker.ch<br>Date: Wednesday, December 31, 2008, 7:19 PM<br><br><div id="yiv1434341594">
In order to meet the criteria for their formula IMHO, you need a
scenerio where you have time for at least three TCP packets to leave
the sender before you get the ACK for the first packet back. The
higher the bandwidth on the link, the sooner you hit critical mass.<br>
<br>
So I would think you need to work back from this:<br>
<br>
Size of TCP packet/speed of line * 3 = time to send three TCP packets.
(You will need to know the size of the TCP packets of course. A
sniffer will help here.)<br>
<br>
(speed of line is the speed of the slowest throttle point and is 4kB/s
in your example.)<br>
<br>
The 'time to send three TCP packets' would need to be at least less
than 1/2 the RTT, IMHO for this to kick in. In other words, if the
'time to send three TCP packets' is less than 1/2 the RTT, the three
packets could leave the sender before the sender has a chance to
receive the first packet ack from the receiver. Only then would
waiting for packet ack start to slow down the FTP protocol.<br>
<br>
This gap between the sending of a packet and the receiption of the ack
is where this limitation kicks in. Now in the old days, Zmodem
protocol was well defined and you knew how many packets would be sent
before the sender would stop sending and wait for an ack. I have not
delved into the TCP packet protocol at this level to determine that
parameter. I am using the number three to help make this explanation
understandable.<br>
<br>
Plus in your setup, you seem to be limiting FTP to 4kB/s, but are
measuring the bit/bye output of the NIC on the FTP server. The 4kB/s
limitation is set before the overhead bits of the TCP packet is added
while you are measuring the combined bit/byte output of the entire
packet via the NIC.<br>
<br>
Lyle<br>
<br>
nangineni praneeth wrote:
<blockquote type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">Oh!i get it now....Thanks for your explanation.But is
there any way for me to show that the network throughput is being
affected by latency...<br>
<br>
Regards<br>
Venkat<br>
--- On <b>Wed, 12/31/08, Lyle Giese <i><a rel="nofollow" class="moz-txt-link-rfc2396E" target="_blank" href="mailto:lyle@lcrcomputer.net"><lyle@lcrcomputer.net></a></i></b>
wrote:<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From:
Lyle Giese <a rel="nofollow" class="moz-txt-link-rfc2396E" target="_blank" href="mailto:lyle@lcrcomputer.net"><lyle@lcrcomputer.net></a><br>
Subject: Re: [mrtg] MRTG and bandwidth delay product<br>
To: <a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:nv_2030@yahoo.com">nv_2030@yahoo.com</a><br>
Cc: <a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:mrtg@lists.oetiker.ch">mrtg@lists.oetiker.ch</a><br>
Date: Wednesday, December 31, 2008, 9:34 AM<br>
<br>
<div id="yiv1133321880"> nangineni praneeth wrote:
<blockquote type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">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 .<br>
<br>
The link below explains it in much more detail<br>
<a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="http://www.speedguide.net/faq_in_q.php?category=89&qid=185">http://www.speedguide.net/faq_in_q.php?category=89&qid=185</a><br>
<br>
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<br>
<br>
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.....<br>
<br>
Regards<br>
Venkat<br>
<br>
<br>
--- On <b>Wed, 12/31/08, Lyle Giese <i><a rel="nofollow" class="moz-txt-link-rfc2396E" target="_blank" href="mailto:lyle@lcrcomputer.net"><lyle@lcrcomputer.net></a></i></b>
wrote:<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From:
Lyle Giese <a rel="nofollow" class="moz-txt-link-rfc2396E" target="_blank" href="mailto:lyle@lcrcomputer.net"><lyle@lcrcomputer.net></a><br>
Subject: Re: [mrtg] MRTG and bandwidth delay product<br>
To: <a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:nv_2030@yahoo.com">nv_2030@yahoo.com</a><br>
Cc: <a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:mrtg@lists.oetiker.ch">mrtg@lists.oetiker.ch</a><br>
Date: Wednesday, December 31, 2008, 8:37 AM<br>
<br>
<div id="yiv1695607579"> nangineni praneeth wrote:
<blockquote type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">Hello everyone....<br>
<br>
I am working in a lab environment...This is how configured my
network.....<br>
<br>
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....<br>
<br>
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......<br>
<br>
BDP=0.340*8kBps=2.72kB/s<br>
<br>
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...<br>
<br>
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....<br>
<br>
I wish you all a good new year ahead..<br>
Regards<br>
Venkat<br>
</td>
</tr>
</tbody>
</table>
</blockquote>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
Lyle Giese<br>
LCR Computer Services, Inc.<br>
<br>
<br>
<br>
</div>
</blockquote>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
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.<br>
<br>
I don't think 8kilobytes/second is fast enough to meet that criteria,
in order for their formula to engage.<br>
<br>
Lyle<br>
<br>
</div>
</blockquote>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<br>
</div></blockquote></td></tr></table><br>