[Iccrg] Re: [tcpm] ECN feedback discussion

[John Leslie]

Scheffenegger, Richard <rs at netapp.com> wrote:
> 
> During the TCPM session, Matt Mathis made an interesting remark on the
> microphone. To paraphrase (my understanding), current marking schemes
> (RED, CoDel, PIE,...) assume that ECN marks get treated like loss by
> the end systems. Therefore, they employ a "low density" marking scheme,
> with marks expected at an (average) rate of around 3% or so at maximum.

   Actually, 3% loss is pretty bad, and 3% ECN-marking would be very much
worth avoiding. Nonetheless, "low-density" can rise that high without
seriously damaging the transport.

> Alternative schemes, that start getting deployed at this time, have
> very simple marking schemes in the network, and give more information
> to the end systems for processing and reaction there. As a side effect,
> these newer schemes may run as high as 100% marking for certain periods
> (longer than a single flows RTT), so they could be classified as
> "high density" marking scheme.

   DCTCP fits this model. Alas, I don't think we all understand it...

> Later on, Bob noted, that since ECN Nonce is virtually nonexistent
> (I know only one stack with partial support), why not re-define ECT(1)
> to be used by high density marking schemes, keeping ECT(0) for low
> density schemes (as deployed today).

   This would have been a much better initial design!

> For newer stacks, this would allow an even more fine grained reaction
> to ECN marking levels...

   With 100% deployment, yes...

> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the
> same meaning for existing ECN stacks as ECT(0)) would not be addressed,

   It might be possible to define a protocol for sender and receiver to
agree to treat ECT(1) this way; but I'm not optimistic about adoption.
It should be workable for research, though...

> but then again, current ECN is also virtually not deployed, according
> to recent studies.

   There's quite a bit of "deployed but disabled" AFAICT.

> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would
> also need to have an impact on the future signaling  / feedback scheme
> used for TCP (DCCP and SCTP would be able to cope already, afaik).

   I believe SCTP could, with near-trivial changes, get both ends to
agree on this difference for ECT(1). I'm not familiar enough with DCCP
to say for sure, but at first blush it appears there are enough
reserved bits to adapt. (It looks non-trivial, though.)

   Looking ahead, I doubt that two flavors of ECN will be sufficient
for all needs. Getting beyond one flavor is _very_ much worth doing;
but I think we need a final target of at least eight flavors.

--
John Leslie <john at jlc.net>