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