From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8510E3B29E; Sun, 10 Mar 2019 17:28:23 -0400 (EDT) Received: by mail-qt1-x82c.google.com with SMTP id z25so2963983qti.13; Sun, 10 Mar 2019 14:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4JWYl/k5svyy6Fv7MIIuVJM8V78GF5EAg/3l0MO+bv4=; b=UovyEmMapuhyZ2iw0OevlS1I/YNevmnQZ4fls+dMTq6j/GAyFz3zsv5N7uff9X9L3l bWUNKbaj+9XuKy0OWCBObBpjAgcCsARVCj8yYUZiGQzow142zcRDhWHi2APX65LK9Mgm BQlultGBAaEqTXVhOwKjWYt88YgsbtV0n0FbC+g5T4ljzcRm8AInWBOZs8i6E0MzFO3v LX/LNJL/mhNWg4ML/3ZiPmizEsYEZzKKI88nxCIZ6FEU6ZkEke5vGwZ0nYhtZh4BSRSx ewpHNg6er917EgMT1KAlItQyj5TEmYPHXV6kPOyo86itUcbApOUJG4ASFZYekVtoDKPp +aZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4JWYl/k5svyy6Fv7MIIuVJM8V78GF5EAg/3l0MO+bv4=; b=eJxBIwmP+0lSqrVjU48n6kWWCQPLwtnmzW0LEhSnCtnFd6TyKtWGGITG5MJKb3UkKE RVawaMI1vu+1xnEac8Je0D0DC9aay9MaGdDsRX9fXHnDy1UhINo6D+JxDYipN8dYvWWA WPa4vMLN6Tw0WNC0SpE6TJQwyy0TjJ95/JhzR8LsojTmOsMTt1Gx06vr3LpZBd0Pw9aT Xrl400rCpTg3OPUclTdCXwm2WEhoJd3HrSUnrYPgUYElaCBDuFROh/zedBtpyWIR1snJ 91CbVHj5uYq6X8TvB5ev5j5r7dAKGzK0fBH26vU1nH3ZQEAV3HL8RjDZD/XG0bc6zSiI aomA== X-Gm-Message-State: APjAAAUYdJ0OOkNzE0mzT254Kh8SAPkwoBxiaYqMEBdhmk1Xp+hArsMv FBB9bMN/LD2lrjCYpXCNw6N06vpV5XKuBuGnQqc= X-Google-Smtp-Source: APXvYqzb5uctQDkzu+jtiBnLq8YJ8r/89dICV/R8IE6pjYwKzxphu6w1BW1PbnoI5Wf9tfUyqT20KDDzPcl32oo3plY= X-Received: by 2002:ac8:88a:: with SMTP id v10mr6472236qth.136.1552253303018; Sun, 10 Mar 2019 14:28:23 -0700 (PDT) MIME-Version: 1.0 References: <550C0248-1704-49DA-ABDC-49A91E0AC6F3@akamai.com> In-Reply-To: From: Dave Taht Date: Sun, 10 Mar 2019 14:28:11 -0700 Message-ID: To: "Holland, Jake" Cc: bloat , Cake List , "codel@lists.bufferbloat.net" , "ecn-sane@lists.bufferbloat.net" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft - X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 21:28:23 -0000 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 wrote: > > On Sun, Mar 10, 2019 at 12:08 PM Holland, Jake wrot= e: > > > > 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 > > > > > > =EF=BB=BFOn 2019-03-10, 11:07, "Dave Taht" wrote: > > > > I would love to have some fresh eyeballs on a new IETF draft for th= e > > TSVWG we intend to submit tonight. > > > > I've attached the html for easy to read purposes, but I would prefe= r > > that folk referred back to the github repository for the most curre= nt > > version, which is here: > > > > https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-mor= ton-taht-SCE.txt > > > > and in open source tradition, discuss here, or file bugs, and submi= t > > pull requests to the gitub. > > > > The first draft (of 3 or more pending), is creating the SCE codepoi= nt > > 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 T= CP > > 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 ot= her > > work in the github repo. > > > > THX! > > > > -- > > > > Dave T=C3=A4ht > > CTO, TekLibre, LLC > > http://www.teklibre.com > > Tel: 1-831-205-9740 > > > > > > > -- > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 -- Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740