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

[Dave Taht]

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