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

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

the SCE draft is now  submitted to IETF! I'm too tired to figure out
what timezone conversion the UTC deadline is in PDT right now, and I
guess the chairs need to move it into the tsvwg working group instead
of individual submissions... and I have no idea what else I missed in
the ietf processes. Ironically the ietf tools do not take upper case,
so I had to rename the draft in the github repo. this is where it lies
now:

https://datatracker.ietf.org/doc/draft-morton-taht-sce/


On Sun, Mar 10, 2019 at 2:28 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> AHA!
>
> http://www.hjp.at/doc/rfc/rfc8311.html#sec_3
>
> While the ECN nonce works as specified, and has been deployed in
>    limited environments, widespread usage in the Internet has not
>    materialized.  A study of the ECN behavior of the top one million web
>    servers using 2014 data [Trammell15] found that after ECN was
>    negotiated, none of the 581,711 IPv4 servers tested were using both
>    ECT codepoints, which would have been a possible sign of ECN nonce
>    usage.  Of the 17,028 IPv6 servers tested, four set both ECT(0) and
>    ECT(1) on data packets.  This might have been evidence of use of the
>    ECN nonce by these four servers, but it might equally have been due
>    to erroneous re-marking of the ECN field by a middlebox or router.
>
> I'm not sure if I should cite 8311 or not here, rather than the
> original research.
>
> I can't seem to coax our tool to output RFC3168 as normative.
>
>
>
> On Sun, Mar 10, 2019 at 2:11 PM Dave Taht <dave.taht@gmail.com> wrote:
> >
> > 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
>
>
>
> --
>
> 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