[Codel] why RED is not considered as a solution to bufferbloat.

[Jonathan Morton]

Okay, let me walk you through this.

Let's say you are managing a fairly slow link, on the order of 1 megabit.
The receiver on the far side of it is running a modern OS and has opened
its receive window to a whole megabyte. It would take about 10 seconds to
pass a whole receive window through the link.

This is a common situation in the real world, by the way.

Now, let's suppose that the sender was constrained to a slower send rate,
say half a megabit, for reasons unrelated to the network. Maybe it's a
streaming video service on a mostly static image, so it only needs to send
small delta frames and compressed audio. It has therefore opened the
congestion window as wide as it will go, to the limit of the receive
window. But then the action starts, there's a complete scene change, and a
big burst of data is sent all at once, because the congestion window
permits it.

So the queue you're managing suddenly has a megabyte of data in it. Unless
you do something about it, your induced latency just leapt up to ten
seconds, and the VoIP call your user was on at the time will drop out.

Now, let's compare the behaviour of two AQMs: Codel and something almost,
but not entirely, unlike Codel. Specifically, it does everything that Codel
does, but at enqueue instead of dequeue time.

Both of them will let the entire burst into the queue. Codel only takes
action if the queue remains more full than its threshold for more than
100ms. Since this burst arrives all at once, and the queue stayed nice and
empty up until now, neither AQM will decide to mark or drop packets at that
moment.

Now, packets are slowly delivered across the link. Each one takes about
15ms to deliver. They are answered by acks, and the sender obligingly sends
fresh packets to replace them. After about six or seven packets have been
delivered, both AQMs will decide to start marking packets (this is an ECN
enabled flow). Let's assume that the next packet after this point will be
marked. This will be the receiver's first clue that congestion is occurring.

For Codel, the next packet available to mark will be the eighth packet. So
the receiver learns about the congestion event 120 ms after it began. It
will echo the congestion mark back to the sender in the corresponding ack,
which will immediately halve the congestion window. It will still take at
least ten seconds to drain the queue.

For NotCodel, the next available packet for marking is the one a megabyte
later than the eighth packet. The receiver won't see that packet until
10120 ms after the congestion event began. So the sender will happily keep
the queue ten seconds long for the next ten seconds, instead of backing off
straight away. It will take at least TWENTY seconds to drain the queue.

Note that even if the link bandwidth was 10 megabits rather than one, with
the same receive window size, it would still take one second to drain the
queue with Codel and two seconds with NotCodel.

This relatively simple traffic situation demonstrates that marking on
dequeue rather than enqueue is twice as effective at managing queue length.

- Jonathan Morton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/codel/attachments/20150226/9a830bbc/attachment-0002.html>