Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

[Dave Taht <dave@taht.net>]

Michael Welzl <michawe@ifi.uio.no> writes:

> Just a small clarification:
>
>     
>     
>         
>         To me the switch to head dropping essentially killed the tail
>         loss RTO
>         problem, eliminated most of the need for ecn.
>
>     
>     
>     I doubt that: TCP will need to retransmit that packet at the head,
>     and that takes an RTT - all the packets after it will need to wait
>     in the receiver buffer before the application gets them.
>     But I don’t have measurements to prove my point, so I’m just
>     hand-waving…
>
> I don’t doubt that this kills the tail loss RTO problem.

Yea! I wish we had more data on it though. We haven't really ever looked
at RTOs in our (enormous) data sets, it's just an assumption that we
don't see them. There's terabytes of captures....

> I doubt that it eliminates the need for ECN.

A specific example that burned me was stuarts demo showing screen
sharing "just working", with ecn, on what was about a 20ms path.

GREAT demo! Very real result from codel. Ship it! Audience applauded madly.
fq_codel went into OSX earlier this year.

Thing was, there was a 16ms frame rate (at best, probably closer to
64ms), at least a 32ms jitter buffer (probably in the 100s of ms
actually), an encoder that took at least a frame's worth of time...

and having the flow retransmit a lost packet vs ecn - within a 15ms rtt
- with a jitter buffer already there - was utterly invisible also to the
application and user.

Sooo....

see ecn-sane. Please try to write a position paper as to where and why
ecn is good and bad.

if one day we could merely establish a talmud of commentary
around this religion it would help.