[Ecn-sane] IETF 110 quick summary

Jonathan Morton chromatix99 at gmail.com
Tue Mar 9 14:42:01 EST 2021


> On 9 Mar, 2021, at 9:27 pm, Holland, Jake <jholland at akamai.com> wrote:
> 
>>> …classic ECN traffic will not respond as quickly as L4S…
>> 
>> I know it wasn't you making this claim, Jake, but I have to point out that it's completely false.  Classic ECN transports actually respond *more* quickly to a CE mark than L4S transports.
> 
> Here I meant to talk about an SCE-style low-congestion signal (in
> either 1->0 or 0->1 direction), which would be ignored by a classic
> endpoint but which a high-fidelity endpoint would respond to.
> 
> So I'm not referring to a CE mark here, but rather an SCE mark, as
> I thought Steve was proposing with this bit:
> 
>>> Maybe that is an argument that you can throw at them: if it is safe to
>>> ignore classic ECN, might as well move straight to SCE with non-ECT
>>> traffic shunted off to a separate queue(s).
> 
> Sorry for any confusion there, I'm not in favor of talking past each
> other and I think we probably agree here if I've understood correctly.
> 
> What I was trying to say is that an SCE response (specifically
> including an L4S-using-SCE response, though I think you had some
> intriguing alternate ideas to reduce the effect) would be faster
> than a classic response that ignores SCE and waits for a CE.

Okay, that does make more sense.  I probably wouldn't use "faster" or "not as quickly" to describe that, however.  Such a description only makes sense if you pre-suppose a queue depth that rises monotonically over time.

AIMD and HFCC responses do tend to need different operating points to work efficiently.  HFCC can settle on a steady-state cwnd that is quite close to the true BDP.  AIMD needs the peak queue depth to be significantly higher, to accommodate the deep sawtooth without losing too much goodput.  So it entirely makes sense to set the thresholds for the two types of signalling accordingly.

> I do agree with your explanation that a classic CC responds faster to
> a CE mark than TCP Prague, that's just not what I was trying to talk
> about.

Sure.  But the phrasing sounded so much like arguments that have indeed come from the L4S team - I'm sure you remember all the marketing BS that had to be cut out of their drafts, and there's still a lot of stuff there which I think is not supported (at best) by the data.

 - Jonathan Morton


More information about the Ecn-sane mailing list