Re: [Bloat] Bufferbloat research: Help required

[Simon Barber <simon@superduper.net>]

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