Re: [Ecn-sane] sce materials from ietf

["Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>]

> there are no minutes posted.
> 
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-81-some-congestion-experienced-00
> 
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-some-congestion-experienced-in-tcp-00

The above 2 decks are identical.  Jonathan did not get any time
during tsvwg, so I reposted the whole deck to tcpm, in which I
also did not get any time to present.

BUT, and that is a all caps BUT, good stuff happened for SCE
forward progress during the meetinhgs none the less.  We did
infact get an announcement that we have asked for adoption of
draft-morton-tsvwg-sce, with a 25 hand count on who has read
the draft, which by my rough estimate was more than 1/4 of
the room.

During the tcpm session the issues around allocation of bit 7
for AccECN may of been worked out, that draft (AccECN) is becoming
a proposed standard, which can do the IANA allocation, and Mira
at least continues to affirm that bit 7 can be used for other
purposes after an AccECN negotiation failure when it falls back
to RFC3168 ECN, so we (SCE) believe we do have a path forward on
our alternate use for bit 7.

The tsvwg chairs, and the work group itself now needs to discuss
the 2 experiment problem, the conflicts and compatibilities between
the 2, and just how to deal with the situation.

YOUR (that being all the list members of ecn-sane, and the larger
bufferbloat community) inputs and helps are highly desired in
this process.

The SCE teams possition is that L4S is fundementally flawed in
its use of the ECT(1) code point as a "Traffic Classifier" since
that leads to the end nodes telling the network the traffic is
special, aka treat me differently than any other traffic, and
is likely to lead to abuse, which may possibly lead to bleaching
of the code point, which would be bad for everyone.

It would be much nicer to use this last code point, 1/2 a bit,
for a high fidelity signal from the network to the receiver
of the level of congestion in a fully backwards to RFC3168
way.

We (the SCE team) also feel that L4S is overly complex and continues
to grow complexity as problems with it are exposed.  (Recently it
has become apparent that protecton from RFC3168 behavior is needed,
and thus a new proposal and a new chunk of code are being
developed to deal with this issue.


> Dave T?ht
-- 
Rod Grimes                                                 rgrimes@freebsd.org