From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 43CA83B29E; Sun, 10 Mar 2019 17:49:23 -0400 (EDT) Received: by mail-qk1-x729.google.com with SMTP id x9so1633318qkf.0; Sun, 10 Mar 2019 14:49: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=UoD4RenkLg1pan1JfrThXrXkSikdAh6IFtm/JxtExoY=; b=kJSrgVkFd1JulOXIZS3YpbA1A3sKOYc88QSIfmKXtrr34kfCielSwbPmT/yTprtDL/ p8WlI4qijpyNRMZGcb4U+pzbpZfXFxZsmHypP9dz5DEDOWS5T2GSBBPCUPUoPNCVIiEn ST03yBqAHKzZ1azYDmHZ5wKPzSAiDneyQ9DI2QrZAQd54gZj5uW6hThXFdddxRVJ5YMl edkEvZmEub8gC2WEn3SxrMqbkQ+pyWrJByzq9bmLPEqY7XTIjyLYbApUFBxqRHaIKQo0 4uWyKZLfSGA/kTVoWsLRQ8Nfy2m4//OyhosMtLV54Zzlpv58Mji220xKBEdwz1n95LPS 2xlg== 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=UoD4RenkLg1pan1JfrThXrXkSikdAh6IFtm/JxtExoY=; b=noMAho+hXiIeMovU7El3m8GczRWyS8MAEPcQtdth0dkPEzNRiiK3UgfXfWWLOPNkUO ORUojoOoJfpvUzVRXraRfMsPgK9qy20w+eFHGKh8RXGgKUXt8LEkJB1/7GwFPI8EPSdo tx4kBfxlxVkLMItAp6CzMVQ4M4to+jE0Njimq5BJeXXL5i8e5mqEPBDzNWeKMhkAVg5N dTjlZlzQuCbqNZtrkHxP2tvZ0hH/01xQhtK/t4l30KI+pM/7G66Wb7+4GPY/Thj3BBdS uD3mFjm/t5crZRbT+MfGMOaR8NqzovdClT63FBGmZEieVYuj3fw2uEWx/tLOanhZfhuO ZHCA== X-Gm-Message-State: APjAAAWal4uhUWyFPGj5e+Kds994OeXZ7c3FPpPfkKzJ9gzIANvHz4Ei DDzbwevYw2CtXK4BmjdYQ4FCny+iUa4E8amDmaM= X-Google-Smtp-Source: APXvYqwO0egThCQ44Y4bp9Lrvmvzc3SD2FAURNvIUfXMRW1O0D0kb8K/EpErBldhcL1wujJvJn0FRTQaT/4GHhh5WCU= X-Received: by 2002:a37:3d7:: with SMTP id 206mr21328680qkd.164.1552254562739; Sun, 10 Mar 2019 14:49:22 -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:49: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: [Ecn-sane] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft - X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 21:49:23 -0000 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 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 wrote: > > > > On Sun, Mar 10, 2019 at 12:08 PM Holland, Jake wr= ote: > > > > > > 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 unus= ed, > > > 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" wrot= e: > > > > > > 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 pre= fer > > > that folk referred back to the github repository for the most cur= rent > > > version, which is here: > > > > > > https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/draft-m= orton-taht-SCE.txt > > > > > > and in open source tradition, discuss here, or file bugs, and sub= mit > > > pull requests to the gitub. > > > > > > The first draft (of 3 or more pending), is creating the SCE codep= oint > > > and defining the state machine, is pretty short, and we think the > > > basic concept solves a zillion problems with ECN in one stroke. I= t's > > > easy to implement (one line of code in codel), backward compatibl= e > > > 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 dou= bt > > > 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=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 --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740