[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 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>