Hi Dave, You and John have my enthusiastic +1.
It's a frank relief to read this draft after trying to figure out L4S, and I think the basic core concept upon which to build the actual response systems is very well separated and very well framed here. Please submit this and present, I humbly beg you. It seems to me a strictly better use of ECT(1), even though there's still probably a few hundred pages' worth of catching up to do on draft-writing to nail down details. I have a few minor comments for your consideration, but please don't let them stop you from posting before deadline, if any are hard to integrate. It would be better to ignore them all and post as-is than to get hung up on these: 1. "Some" in "Some Congestion Experienced" is maybe misleading, and arguably has the same meaning as "Congestion Experienced". I was thinking maybe "Pre-Congestion Experienced" or "Queue Utilization Observed", or if you want to preserve "SCE" and the link to CE (which I do agree is nice), maybe "Slight" or "Sub" instead of "Some", just to try to make it more obvious it's flagging a lesser situation than "there is some congestion". 2. It's easy to accidently read section 5 as underspecified concrete proposals instead of rough sketches for future direction that might be worth investigating. I'll offer an attempt at some language, feel free to edit (or ignore if you think the intro is enough to make the scope sufficiently clear already): The scope of this document is limited to the definition of the SCE codepoint. However, for illustration purposes, a few possible future usage scenarios are outlined here. These examples are non normative. 3. Similarly, I would lower-case the "MAY" and "SHOULD" in section 5.2 for receiver-side handling in TCP--it's not clear this will ever be a good idea to do without more explicit signaling thru new opts or whatever, and granting permission here seems like asking for trouble that's just not necessary. And a few that I'd defer if I were you, but I'd like to see sometime in at least a post-Prague version or list discussion: 4. an informative reference or 2 would be a welcome addition in Section 3: Research has shown that the ECT(1) codepoint goes essentially unused, with the "Nonce Sum" extension to ECN having not been implemented in 5. Should this must be MUST in Section 4? If not, why not? New SCE-aware receivers and transport protocols must continue to Thanks guys, nice work and good luck! Cheers, Jake On 2019-03-10, 11:07, "Dave Taht" <[email protected]> wrote: I would love to have some fresh eyeballs on a new IETF draft for the TSVWG we intend to submit tonight. I've attached the html for easy to read purposes, but I would prefer that folk referred back to the github repository for the most current version, which is here: https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-morton-taht-SCE.txt and in open source tradition, discuss here, or file bugs, and submit pull requests to the gitub. The first draft (of 3 or more pending), is creating the SCE codepoint and defining the state machine, is pretty short, and we think the basic concept solves a zillion problems with ECN in one stroke. It's easy to implement (one line of code in codel), backward compatible with all the RFCs, and somewhat incompatible with the stalled out TCP Prague/dualpi effort in the IETF. We have several other drafts in progress which I increasingly doubt we'll finish today, but I think only this one is required to get an audience in the tsvwg at the coming IETF meeting. If ya have any comments and spare time today, I'd like to get the first draft in tonight, and the filing deadline for final drafts is sometime tomorrow. It may help for context to review some of the other work in the github repo. THX! -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
