[Bloat] Solving bufferbloat with TCP using packet delay

Dave Taht dave.taht at gmail.com
Wed Mar 20 11:55:07 EDT 2013


On Wed, Mar 20, 2013 at 11:36 AM, Steffan Norberhuis
<steffan at norberhuis.nl> wrote:
> Hello Everyone,
>
> For a project for the Delft Technical University myself and 3 students are
> writing a review paper on the buffer bloat problem and its possible
> solutions. I also subscribed to this mailinglist and see alot of proposed
> solutions to be AQM.
>
> But hardly any talk about solving buffer bloat by using a TCP variant that
> that uses packet delay as a way to determine the send rate. We did not come
> across any papers that argue that these TCP variants are not a good
> solution. We went to several professors with the question if TCP using
> packet delay was not a good solution. But we did not get a concise answer.
> In our view AQM needs alot of new hardware to be implemented and a TCP
> variant would perhaps be easier to implement and is also able to solve
> bufferbloat.

LPCC has been pursued for a decade. the new AQM stuff outperforms it
in nearly every respect.

I'd put together what I'd hoped to be a foundational paper on it, in
conjunction with some LEDBAT researchers. I couldn't get it published
in full, full version is here:

www.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf

I have not had a chance to work on the successor paper, running the
same sorts of tests, using sfqred, or fq_codel. I have tons of data,
just no time to process it and structure the experiments repeatably.

The issue has also been discussed on this list and others, for ages.

>
> So I have a few questions I would like to ask you:
> - Is TCP using packet delay considered as part of the solution for
> bufferbloat?

I think paced TCP shows more promise than any of the delay based TCPs,
at least at present, on the edge, for things like DASH traffic. There
are other possibilities being discussed in the rmcat ietf group.

> - What are the problems of TCP delay variants that keep it from solving
> bufferbloat?
>
> - What are the drawbacks of the TCP delay variants that would favor AQM over
> TCP?

Nothing competes with packet loss/ECN marked based TCP effectively
that we know of. A few, come fairly close.

> - What are the advantages of TCP delay varaints that would favor TCP over
> AQM?

You, know, at this point, my answer is - Install Linux, get the RRUL
test, enable every known variant of TCP, and try them with and without
the AQMs that have been developed and now available in linux, with
whatever variety of traffic you like, and get back to us with the
results. It'll only take a day or so, to try it out. See the iccrg
details for how to get started, or the stanford and MIT presos.

http://netseminar.stanford.edu

http://www.ietf.org/proceedings/86/slides/slides-86-iccrg-0.pdf

> Best regards,
>
> Steffan Norberhuis
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



More information about the Bloat mailing list