Re: [Bloat] Solving bufferbloat with TCP using packet delay

[Oliver Hohlfeld <oliver@net.t-labs.tu-berlin.de>]

Steffan,

> I also subscribed to this mailinglist and see alot of proposed
> solutions to be AQM.

Well, AQM is one possible answer. While AQM is discussed for years, it
never found widespread deployment. Proper RED configuration was close to
black magic. Based on preliminary results, Codel seems a promising
candidate to bring AQM back into the game (at least for edge routers).

However, the most basic fix is reducing the buffer size in exacerbated
buffer configurations (bufferbloat is mostly a problem in the edge.
Buffers in the core are often reasonably sized). When buffers can not be
changed, AQM provides a good fix.

Another aspect is managing congestion in the network (e.g., by QoS
mechanisms). We recently investigated the problem from the perspective
of end-users (see [1]) and found congestion to be a key aspect that
reduces user satisfaction.

[1] BufferBloat: How Relevant? A QoE Perspective on Buffer Sizing.
http://downloads.ohohlfeld.com/paper/bufferbloat-qoe-tr.pdf

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

I do have a few concerns:

- There is no flag day that would make users switch to new TCP variants.
There are plenty of TCP flavors used already. How would you ensure
deployment of a delay sensitive variant?
- While TCP traffic is dominant in the Internet's traffic mix, many
real-time (or delay sensitive) applications use UDP. In these cases,
your fix would not apply.

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

Think also about the widespread deployment of a new TCP variant. How
easy is it to get an TCP update deployed on all the different software
stacks that are out there? To me, it appears to be practically infeasible.

> 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?
> 
> - 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?
> 
> - What are the advantages of TCP delay varaints that would favor TCP
> over AQM?

Sounds like a nice research problem. I'd love to see an extensive
evaluation on this.

Oliver