Hi David Sir,

Sorry for replying late..but i was v. busy with some other work.

Thanks for the detailed explaination

and yes ofcourse, it helped.

Thanks a lot for clearing my doubts.

On Sun, Mar 29, 2015 at 11:32 PM, David Lang <david@lang.hm> wrote:

> On Sun, 29 Mar 2015, sahil grover wrote:
>
>  can you please explain me  the concept of  delay-bandwidth product,window
>> size and buffer size(or something related with pipe size and packets in
>> flight).
>>
>
>
> These are several different concepts, all related to network perfromance,
> but most unrelated to buffer sizing.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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
>
> 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
>
>
> 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.
>
> Does this help?
>
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>