[Ecn-sane] sce materials from ietf

[Rodney W. Grimes]

> > 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.

Correction, Jonathan did get 6 minutes, iirc.  

> 
> 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 at freebsd.org
> _______________________________________________
> Ecn-sane mailing list
> Ecn-sane at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ecn-sane
> 
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org