<div dir="ltr"><span style="color:rgb(51,51,51);font-family:'normal arial',sans-serif;font-size:16px;line-height:20px">Hi David Sir,</span><div><br></div><div>Sorry for replying late..but i was v. busy with some other work.<div><br></div><div>Thanks for the detailed explaination</div><div><br></div><div>and yes ofcourse, it helped.</div><div><br></div><div>Thanks a lot for clearing my doubts.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 29, 2015 at 11:32 PM, David Lang <span dir="ltr"><<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 29 Mar 2015, sahil grover wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
can you please explain me  the concept of  delay-bandwidth product,window<br>
size and buffer size(or something related with pipe size and packets in<br>
flight).<br>
</blockquote>
<br>
<br></span>
These are several different concepts, all related to network perfromance, but most unrelated to buffer sizing.<br>
<br>
Any network connection is either 100% used, or idle if you look at a small enough timeframe. When the network connection finishes sending one packet, it is idle until the next packet is available to send. If there is no buffer, the connection is idle until the software generates new data to send. since this takes time, the connection will be idle. As a result, you want to have some buffer so that the software can generate the traffic a little earlier than it's needed so that as soon as the network finishes sending one packet, it has the next packet available to send.<br>
<br>
when you have a router that is receving packets from multiple computers and sending it out one link, buffers become even more important, if you have two computers send you a packet at the same time, without a buffer youc an only send one and the other will have to be dropped. so you need to have a buffer to hold the second packet so you can send it out as soon as you have time.<br>
<br>
bufferbloat is when the buffers are "too large" for the output connection and you end up with "too much" data sitting in the buffers waiting to be sent. The problem with trying to size buffers is that how long it takes to transmit the data in the buffer depends on how large the packets in teh buffer are and how fast the connection is. Traditionally, buffers were sized in terms of X packets. If you have a buffer that can hold 10ms worth of 75 byte packets at 1Gb/sec, but you are connected to a DSL line with an upload spped of 1Mb/sec and are sending 1500 byte packets, then your buffer now holds 200,000ms worth of traffic.<br>
<br>
TCP ramps up it's sending speed until it looses packets (or gets an ECN signal), no packets will be dropped until the buffer fills up (in addition to the traffic that gets sent), so the buffer will fill up and everything that you try to do, including DNS lookups, gaming, VoIP, etc is going to be delayed by how long it takes to get through the buffer.<br>
<br>
<br>
window size, delay-bandwidth product, etc are a different aspect of the network stack. they limit a little bit how much traffic a single TCP connection will try to send without receiving any ack packets for the data. The idea is that if you have a 1Gb/s connection, and a 1sping time, to keep the connection full you should have 1Gb of taffic "in flight" (i.e. that you have sent and not yet received acks for). If your window of allowd unacked data is less than this, then you send your limit, then the connection goes idle until the receiving side sends the asks<br>
<br>
Since the system doesn't actually know how long the path is, or the available bandwidth, it again is guessing this and ramping it up until it runs into trouble and then slows down<br>
<br>
<br>
so back to your questions, the delay of the link times the bandwidth of the link (delay-banseidth produt) determins the ideal window size for a given TCP connection. This determins the minimum size of a buffer of unacknowleged packets that a system has transmitted. This has _nothing_ to do with the buffer size for packets that a system or rotuer is waiting to transmit. Bufferbloat happens on the buffer for packets that are waiting to be transmitted.  a few ms worth of buffering for packets waiting to be transmitted is necessary to keep the connection busy, bufferbloat happens when these queues get much larger than this minimum value. There isn't a hard limit that separates bloat from non-bloat, but if your queues are over a second, you are very clearly way beyond a reasonable size buffer. 10s of ms is probably reasonable, 100s of ms is probably not.<br>
<br>
Does this help?<span class="HOEnZb"><font color="#888888"><br>
<br>
David Lang</font></span><br>_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
<br></blockquote></div><br></div>