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

[Dave Taht <dave.taht@gmail.com>]

On Sun, Mar 10, 2019 at 12:08 PM Holland, Jake <jholland@akamai.com> wrote:
>
> 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

I have been trying to find that presentation or paper or talk or rfc
for days now. I *know* it went by sometime in the past 2 years, I had
my aha! moment - and I keep drawing a blank. Might have been something
brian trammel did, I simply cannot remember.

I definately want to cite that, and I sure hope I'm not delusional.

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


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740