[Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft -

[Holland, Jake]

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" <dave.taht at gmail.com> 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