[Bloat] Requirements for bufferbloat to occur

[Bloat] Requirements for bufferbloat to occur

[sahil grover]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

Hi

Anyone please answer my questions:

(1) All say bufferSize should be set very large for bufferbloat to occur.

But how much large?? is there any condition?

Can we randomly give any large value and can set traffic accordingly so
that packets

 remains in queue most of time.


will this  be enough for bufferbloat condition?



(2) even after setting buffersize very  very large,  if packets get dropped
due to buffer
overflow  when heavy traffic is there.

is it bufferbloat?

i mean if  upper limit of buffersize is reached and packets are dropped.

is it also a case of bufferbloat or

sholud we take care that maximum limit of buffersize is never reached and
no

packet  drop is there due to queue overlow for bufferbloat condition?


please please reply i really need it.

[-- Attachment #2: Type: text/html, Size: 2404 bytes --]

Re: [Bloat] Requirements for bufferbloat to occur

[Jonathan Morton]

> On 29 Mar, 2015, at 11:04, sahil grover <sahilgrover013@gmail.com> wrote:
> 
> (1) All say bufferSize should be set very large for bufferbloat to occur.
>  
> But how much large?? is there any condition?

There’s a clue in the name: if the buffer is significantly larger than it needs to be (and is unmanaged), we call that bufferbloat.

If the buffer is too small to absorb a typical burst of packets, the resulting increase in packet loss will cause a reduction in throughput.  The correct size for an unmanaged buffer is typically the delay-bandwidth product, which enables it to absorb a transitory burst from a single TCP flow.

However, determining the delay is difficult a priori, and frequently differs substantially between different flows on the same connection.  So we usually make some reasonable assumption about the delay component of that formula: 100ms is typical for a broadband connection to the public Internet, and VoIP can just-about cope with that in practice.

Or, to put it another way - if the buffer *induces* significantly more than 100ms delay under load, that is bufferbloat.

> (2) even after setting buffersize very  very large,  if packets get dropped due to buffer  
> overflow  when heavy traffic is there.
> 
> is it bufferbloat?

Yes.  Packet loss has nothing to do with it - it’s the induced delay that matters.

> sholud we take care that maximum limit of buffersize is never reached and no 
> packet  drop is there due to queue overlow for bufferbloat condition?

Extremely large buffers are usually the result of hardware engineers naively attempting to achieve zero packet loss, by providing buffers larger than the TCP receive window size.  (That is a futile goal - rwnd is unlimited in modern operating systems which support window scaling.)  However, zero packet loss is not a necessary condition.

AQMs often deliberately drop packets in order to signal congestion to the endpoints.  Under some circumstances, this can actually result in less overall packet loss than on an unmanaged buffer.  Even without ECN, the AQM rarely causes burst losses, whereas overflowing an unmanaged queue often does.  With ECN, an AQM can often signal congestion sufficiently well without dropping any packets at all.

 - Jonathan Morton

Re: [Bloat] Requirements for bufferbloat to occur

[sahil grover]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

Thanks a lot for replying.

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).

 because i am unable to understand it from papers/articles etc.

And the way you explained to me everytime, was very effective.

So please help in making me understand this(BDP,window size) concept too .





On Sun, Mar 29, 2015 at 2:09 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

>
> > On 29 Mar, 2015, at 11:04, sahil grover <sahilgrover013@gmail.com>
> wrote:
> >
> > (1) All say bufferSize should be set very large for bufferbloat to occur.
> >
> > But how much large?? is there any condition?
>
> There’s a clue in the name: if the buffer is significantly larger than it
> needs to be (and is unmanaged), we call that bufferbloat.
>
> If the buffer is too small to absorb a typical burst of packets, the
> resulting increase in packet loss will cause a reduction in throughput.
> The correct size for an unmanaged buffer is typically the delay-bandwidth
> product, which enables it to absorb a transitory burst from a single TCP
> flow.
>
> However, determining the delay is difficult a priori, and frequently
> differs substantially between different flows on the same connection.  So
> we usually make some reasonable assumption about the delay component of
> that formula: 100ms is typical for a broadband connection to the public
> Internet, and VoIP can just-about cope with that in practice.
>
> Or, to put it another way - if the buffer *induces* significantly more
> than 100ms delay under load, that is bufferbloat.
>
> > (2) even after setting buffersize very  very large,  if packets get
> dropped due to buffer
> > overflow  when heavy traffic is there.
> >
> > is it bufferbloat?
>
> Yes.  Packet loss has nothing to do with it - it’s the induced delay that
> matters.
>
> > sholud we take care that maximum limit of buffersize is never reached
> and no
> > packet  drop is there due to queue overlow for bufferbloat condition?
>
> Extremely large buffers are usually the result of hardware engineers
> naively attempting to achieve zero packet loss, by providing buffers larger
> than the TCP receive window size.  (That is a futile goal - rwnd is
> unlimited in modern operating systems which support window scaling.)
> However, zero packet loss is not a necessary condition.
>
> AQMs often deliberately drop packets in order to signal congestion to the
> endpoints.  Under some circumstances, this can actually result in less
> overall packet loss than on an unmanaged buffer.  Even without ECN, the AQM
> rarely causes burst losses, whereas overflowing an unmanaged queue often
> does.  With ECN, an AQM can often signal congestion sufficiently well
> without dropping any packets at all.
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 4117 bytes --]

Re: [Bloat] Requirements for bufferbloat to occur

[sahil grover]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

.

On Sun, Mar 29, 2015 at 10:04 PM, sahil grover <sahilgrover013@gmail.com>
wrote:

> Thanks a lot for replying.
>
> 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).
>
>  because i am unable to understand it from papers/articles etc.
>
> And the way you explained to me everytime, was very effective.
>
> So please help in making me understand this(BDP,window size) concept too .
>
>
>
>
>
> On Sun, Mar 29, 2015 at 2:09 AM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
>
>>
>> > On 29 Mar, 2015, at 11:04, sahil grover <sahilgrover013@gmail.com>
>> wrote:
>> >
>> > (1) All say bufferSize should be set very large for bufferbloat to
>> occur.
>> >
>> > But how much large?? is there any condition?
>>
>> There’s a clue in the name: if the buffer is significantly larger than it
>> needs to be (and is unmanaged), we call that bufferbloat.
>>
>> If the buffer is too small to absorb a typical burst of packets, the
>> resulting increase in packet loss will cause a reduction in throughput.
>> The correct size for an unmanaged buffer is typically the delay-bandwidth
>> product, which enables it to absorb a transitory burst from a single TCP
>> flow.
>>
>> However, determining the delay is difficult a priori, and frequently
>> differs substantially between different flows on the same connection.  So
>> we usually make some reasonable assumption about the delay component of
>> that formula: 100ms is typical for a broadband connection to the public
>> Internet, and VoIP can just-about cope with that in practice.
>>
>> Or, to put it another way - if the buffer *induces* significantly more
>> than 100ms delay under load, that is bufferbloat.
>>
>> > (2) even after setting buffersize very  very large,  if packets get
>> dropped due to buffer
>> > overflow  when heavy traffic is there.
>> >
>> > is it bufferbloat?
>>
>> Yes.  Packet loss has nothing to do with it - it’s the induced delay that
>> matters.
>>
>> > sholud we take care that maximum limit of buffersize is never reached
>> and no
>> > packet  drop is there due to queue overlow for bufferbloat condition?
>>
>> Extremely large buffers are usually the result of hardware engineers
>> naively attempting to achieve zero packet loss, by providing buffers larger
>> than the TCP receive window size.  (That is a futile goal - rwnd is
>> unlimited in modern operating systems which support window scaling.)
>> However, zero packet loss is not a necessary condition.
>>
>> AQMs often deliberately drop packets in order to signal congestion to the
>> endpoints.  Under some circumstances, this can actually result in less
>> overall packet loss than on an unmanaged buffer.  Even without ECN, the AQM
>> rarely causes burst losses, whereas overflowing an unmanaged queue often
>> does.  With ECN, an AQM can often signal congestion sufficiently well
>> without dropping any packets at all.
>>
>>  - Jonathan Morton
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4523 bytes --]

Re: [Bloat] Requirements for bufferbloat to occur

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 3940 bytes --]

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

[-- Attachment #2: Type: TEXT/PLAIN, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Requirements for bufferbloat to occur

[sahil grover]

[-- Attachment #1: Type: text/plain, Size: 4438 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 5328 bytes --]