> > 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 rgri...@freebsd.org > _______________________________________________ > Ecn-sane mailing list > ecn-s...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane > > -- Rod Grimes rgri...@freebsd.org _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat