[Bloat] Bufferbloat research: Help required

[Bloat] Bufferbloat research: Help required

[Dauran raza]

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

Hi

My name is Dauran Raza and i am currently doing Masters in Computer Science
from University Paderborn. Currently i am researching on the Problem of
Bufferbloat for a course under Prof Holger Karl. I have been regularly
reading you articles on your websites about this problem and it has been
really helpfull. I have a problem which is not answered so far through any
research paper. I wanted to know is there any difference in Wired and
Wireless networks caused by this problem and can you guide me with any good
paper or article to read on.

Regards
Dauran Raza

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

Re: [Bloat] Bufferbloat research: Help required

[Dave Hart]

On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza <dauran.raza@gmail.com> wrote:
> My name is Dauran Raza and i am currently doing Masters in Computer Science
> from University Paderborn. Currently i am researching on the Problem of
> Bufferbloat for a course under Prof Holger Karl. I have been regularly
> reading you articles on your websites about this problem and it has been
> really helpfull. I have a problem which is not answered so far through any
> research paper. I wanted to know is there any difference in Wired and
> Wireless networks caused by this problem and can you guide me with any good
> paper or article to read on.

I wish you well in your graduate studies, and I commend Prof. Holger
Karl for his interest in the topic.  I am, however, cautious that I
don't want to do your research for you.

Briefly, as you would hopefully anticipate, wireless presents more
challenges to addressing bufferbloat than wired.  For example, the
jitter (delay variability) is much worse than wired, and 802.11n
requires aggregation of multiple packets into one transmission to
achieve its higher throughputs vs. 802.11g, which further increases
jitter and complicates AQM.

Even ignoring wireless, gigabit wired is more challenging than 100
Mbit, again because techniques used to maximize peak throughput (such
as deeper transmit buffers and receive interrupt coalescing) tend to
make bufferbloat more of a challenge.

There's a theme here -- those developing network advancements have
tended to focus on maximizing achievable throughput without enough
consideration of the negative effects on bufferbloat, often (at least
historically) with no understanding of bufferbloat at all.

I pray I have not said too much already, and if I have, please convey
my apologies to Prof. Karl.

I suggest digging into the mailing list archives:

https://lists.bufferbloat.net/listinfo

I'd start with the bloat and bloat-devel lists, then the Codel-related
lists, and possibly other -devel and -commit lists.  Also, if you make
yourself useful in one or more bufferbloat.net projects, you will gain
firsthand knowledge of the issues as well as personal relationships
with people well-versed in the issues.

Thanks for your interest,
Dave Hart

Re: [Bloat] Bufferbloat research: Help required

[Mark Watson]

It's also interesting to note that cellular wireless systems have been designed with a primary objective of reducing packet loss, at the expense of delay and especially delay variability introduced by link layer ARQ and other schemes. This approach maximizes the throughput of a single long-lived TCP connection, which is not an especially common traffic pattern.

Furthermore, the throughput of a cellular wireless radio channel varies by orders of magnitude on fairly rapidly (channel conditions are reassessed hundreds of times per second): what was a reasonable sized buffer for the throughput at one moment becomes a bloated one a fraction of a second later.

Best,

Mark Watson


On Nov 28, 2012, at 8:39 AM, Dave Hart wrote:

> On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza <dauran.raza@gmail.com> wrote:
>> My name is Dauran Raza and i am currently doing Masters in Computer Science
>> from University Paderborn. Currently i am researching on the Problem of
>> Bufferbloat for a course under Prof Holger Karl. I have been regularly
>> reading you articles on your websites about this problem and it has been
>> really helpfull. I have a problem which is not answered so far through any
>> research paper. I wanted to know is there any difference in Wired and
>> Wireless networks caused by this problem and can you guide me with any good
>> paper or article to read on.
> 
> I wish you well in your graduate studies, and I commend Prof. Holger
> Karl for his interest in the topic.  I am, however, cautious that I
> don't want to do your research for you.
> 
> Briefly, as you would hopefully anticipate, wireless presents more
> challenges to addressing bufferbloat than wired.  For example, the
> jitter (delay variability) is much worse than wired, and 802.11n
> requires aggregation of multiple packets into one transmission to
> achieve its higher throughputs vs. 802.11g, which further increases
> jitter and complicates AQM.
> 
> Even ignoring wireless, gigabit wired is more challenging than 100
> Mbit, again because techniques used to maximize peak throughput (such
> as deeper transmit buffers and receive interrupt coalescing) tend to
> make bufferbloat more of a challenge.
> 
> There's a theme here -- those developing network advancements have
> tended to focus on maximizing achievable throughput without enough
> consideration of the negative effects on bufferbloat, often (at least
> historically) with no understanding of bufferbloat at all.
> 
> I pray I have not said too much already, and if I have, please convey
> my apologies to Prof. Karl.
> 
> I suggest digging into the mailing list archives:
> 
> https://lists.bufferbloat.net/listinfo
> 
> I'd start with the bloat and bloat-devel lists, then the Codel-related
> lists, and possibly other -devel and -commit lists.  Also, if you make
> yourself useful in one or more bufferbloat.net projects, you will gain
> firsthand knowledge of the issues as well as personal relationships
> with people well-versed in the issues.
> 
> Thanks for your interest,
> Dave Hart
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 

Re: [Bloat] Bufferbloat research: Help required

[Simon Barber]

Both cellular and wireless lan suffer from the same problem - in some 
situations a packet loss rate of 30% can be optimal operation for best 
throughput before stepping down a rate at the physical layer. Obviously 
TCP was not designed to handle this level of loss, so a 'wire like' 
emulation layer is used, with retries. Unfortunately the number of 
retries is fixed, and non optimal, causing problems.

Simon

On Fri 30 Nov 2012 10:56:59 AM PST, Mark Watson wrote:
> It's also interesting to note that cellular wireless systems have been designed with a primary objective of reducing packet loss, at the expense of delay and especially delay variability introduced by link layer ARQ and other schemes. This approach maximizes the throughput of a single long-lived TCP connection, which is not an especially common traffic pattern.
>
> Furthermore, the throughput of a cellular wireless radio channel varies by orders of magnitude on fairly rapidly (channel conditions are reassessed hundreds of times per second): what was a reasonable sized buffer for the throughput at one moment becomes a bloated one a fraction of a second later.
>
> Best,
>
> Mark Watson
>
>
> On Nov 28, 2012, at 8:39 AM, Dave Hart wrote:
>
>> On Sun, Nov 25, 2012 at 3:21 PM, Dauran raza <dauran.raza@gmail.com> wrote:
>>> My name is Dauran Raza and i am currently doing Masters in Computer Science
>>> from University Paderborn. Currently i am researching on the Problem of
>>> Bufferbloat for a course under Prof Holger Karl. I have been regularly
>>> reading you articles on your websites about this problem and it has been
>>> really helpfull. I have a problem which is not answered so far through any
>>> research paper. I wanted to know is there any difference in Wired and
>>> Wireless networks caused by this problem and can you guide me with any good
>>> paper or article to read on.
>>
>> I wish you well in your graduate studies, and I commend Prof. Holger
>> Karl for his interest in the topic.  I am, however, cautious that I
>> don't want to do your research for you.
>>
>> Briefly, as you would hopefully anticipate, wireless presents more
>> challenges to addressing bufferbloat than wired.  For example, the
>> jitter (delay variability) is much worse than wired, and 802.11n
>> requires aggregation of multiple packets into one transmission to
>> achieve its higher throughputs vs. 802.11g, which further increases
>> jitter and complicates AQM.
>>
>> Even ignoring wireless, gigabit wired is more challenging than 100
>> Mbit, again because techniques used to maximize peak throughput (such
>> as deeper transmit buffers and receive interrupt coalescing) tend to
>> make bufferbloat more of a challenge.
>>
>> There's a theme here -- those developing network advancements have
>> tended to focus on maximizing achievable throughput without enough
>> consideration of the negative effects on bufferbloat, often (at least
>> historically) with no understanding of bufferbloat at all.
>>
>> I pray I have not said too much already, and if I have, please convey
>> my apologies to Prof. Karl.
>>
>> I suggest digging into the mailing list archives:
>>
>> https://lists.bufferbloat.net/listinfo
>>
>> I'd start with the bloat and bloat-devel lists, then the Codel-related
>> lists, and possibly other -devel and -commit lists.  Also, if you make
>> yourself useful in one or more bufferbloat.net projects, you will gain
>> firsthand knowledge of the issues as well as personal relationships
>> with people well-versed in the issues.
>>
>> Thanks for your interest,
>> Dave Hart
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Bufferbloat research: Help required

[Michael Richardson]

>>>>> "Mark" == Mark Watson <watsonm@netflix.com> writes:
    Mark> It's also interesting to note that cellular wireless [DATA] systems
    Mark> have been designed with a primary objective of reducing packet
    Mark> loss, at the expense of delay and especially delay variability
    Mark> introduced by link layer ARQ and other schemes. This approach
    Mark> maximizes the throughput of a single long-lived TCP
    Mark> connection, which is not an especially common traffic
    Mark> pattern. 

A question, given that I inserted [DATA].

I wonder to what extent the pre-LTE systems were designed this way in
part to make sure that voice over data would always be crappy?

The LTE roadmap says that voice is now over data, so it's now in the
carrier's interest to do things differently.

    Mark> Furthermore, the throughput of a cellular wireless radio
    Mark> channel varies by orders of magnitude on fairly rapidly
    Mark> (channel conditions are reassessed hundreds of times per
    Mark> second): what was a reasonable sized buffer for the throughput
    Mark> at one moment becomes a bloated one a fraction of a second
    Mark> later. 

Does ECN help us here?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

Re: [Bloat] Bufferbloat research: Help required

[Simon Barber]

Voice over data can actually work very well in 3G networks (better than 
dedicated voice even), but it requires prioritisation. There is a bunch 
of work going on to enable this in existing networks to support the new 
services that VoLTE will enable, over older networks (Joyn). This is a 
*huge* transition in carrier networks, and will take some time to 
arrive. Even today only 1 US carrier uses VoLTE, all the others switch 
to 3G to make or receive a phone call.

Simon

On Sat 01 Dec 2012 12:53:13 PM PST, Michael Richardson wrote:
>
>>>>>> "Mark" == Mark Watson <watsonm@netflix.com> writes:
>      Mark> It's also interesting to note that cellular wireless [DATA] systems
>      Mark> have been designed with a primary objective of reducing packet
>      Mark> loss, at the expense of delay and especially delay variability
>      Mark> introduced by link layer ARQ and other schemes. This approach
>      Mark> maximizes the throughput of a single long-lived TCP
>      Mark> connection, which is not an especially common traffic
>      Mark> pattern.
>
> A question, given that I inserted [DATA].
>
> I wonder to what extent the pre-LTE systems were designed this way in
> part to make sure that voice over data would always be crappy?
>
> The LTE roadmap says that voice is now over data, so it's now in the
> carrier's interest to do things differently.
>
>      Mark> Furthermore, the throughput of a cellular wireless radio
>      Mark> channel varies by orders of magnitude on fairly rapidly
>      Mark> (channel conditions are reassessed hundreds of times per
>      Mark> second): what was a reasonable sized buffer for the throughput
>      Mark> at one moment becomes a bloated one a fraction of a second
>      Mark> later.
>
> Does ECN help us here?
>