Re: [aqm] ECT(1)

[Jonathan Morton <[e-mail]>]

> On 4 Aug, 2015, at 14:42, Bob Briscoe <[e-mail]> wrote:
> 
> <Seriously>I know what you mean: RFC3168 behaviour is latent in ECN-enabled servers waiting for a client request.
> 
> I have proposed that L4S behaviour is associated with e2e negotiation of new Accurate ECN semantics. Nonetheless, even if an L4S client attempts to negotiate AccECN with a server, if the server only supports classic ECN, the session should{Note 1} fall back to classic ECN. So we will need to distinguish classic ECN from L4S ECN... unless we all agree that AccECN must fall back to drop, even if the other end says it supports classic ECN.
> 
> {Note 1} AccECN is yet to be specified by the IETF, but this is the current thinking, which seems reasonable.
> </Seriously>
> 
>> Furthermore, L4S _can't_
>> eliminate packet drops; and IMHO a packet-drop in an L4S stream
>> must be treated _differently_ than a L4S congestion mark.
> 
> No-one is questioning that behaviour on drop needs to stay as in Reno or Cubic. The question is only over whether behaviour in response to ECN-CE should be distinct from drop behaviour.

It sounds as though ELR and L4S are aiming at the same sort of problem space.  However, I think ELR has some advantages:

1) ELR doesn’t require changes to the response to CE.  In fact, it expects that the RFC3168 behaviour, or something similar to it, remains in place.

2) ELR doesn’t rely on a robust distinction between ELR and classic ECN traffic, and does not require that they be separately queued.  This follows naturally from point 1.

3) ELR uses all three ECN codepoints (omitting Not-ECT) for signalling.  CE is used for urgent reductions, and the distinction between ECT(0) and ECT(1) is used for finer-grained information; losing this information en route is not fatal.  This, I think, is a natural use of the remaining codepoint.

At some point, I’ll get around to writing it up more formally.

 - Jonathan Morton