Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis (Proportional Rate Reduction) as a tcpm work item? INPUT NEEDED
Neal Cardwell <ncardwell@google.com> Thu, 19 November 2020 20:56 UTC
Return-Path: <ncardwell@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7683F3A1229 for <tcpm@ietfa.amsl.com>; Thu, 19 Nov 2020 12:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwjGM0Q01uJ5 for <tcpm@ietfa.amsl.com>; Thu, 19 Nov 2020 12:56:26 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6F03A1219 for <tcpm@ietf.org>; Thu, 19 Nov 2020 12:56:25 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id x11so3828522vsx.12 for <tcpm@ietf.org>; Thu, 19 Nov 2020 12:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u3p6mGz5Yq06DQtaV3ij8nPLJ8NYgt7N92DjnC5RV4k=; b=wSsZBf+jmD1oNs69TEQbWxH23MP5cvDzYKcwAzJCpUmVJ2ZVR8o5FkNxD67xfm/AeI YVOsXk1wXyDkRgvxU/1rC02XTrXaSpRJSzxVQGG8H3gwq7rfRi9jTD2sSJHEy9xFAhu6 UeH2EsxQjh5o68WA4UWBmxShXt9qvwrrtFoNjYE9rj28v2rDS2/vHxjH+1fI091CeCKZ 8oTO8RN2DAGlqUD3WNJxm0pFl987xG3jZ3GQ4ZZOh7WO1TlB6/DGr6rSIjsY49JtpMcb cgyw88Cjb0xB1930zGSb57Rnm8/2+JF/YnkdhWOeidX3W4mxgBc8qbwEOAeLahaxBGIZ TOaw==
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; bh=u3p6mGz5Yq06DQtaV3ij8nPLJ8NYgt7N92DjnC5RV4k=; b=MA32JFOCKT7AHMaE0GAB/NwySWKL6FZxX+DJdvP4CA2BXJMqceX7oLxDB9OxC2vfCZ j3ER+R6G+p/cgWTFICFc7ZRQDiJ7TY0I4f+vX454jcm8akqLuGg0jzrhJKYMJnLQXBMy C6muIzkndmBFWDqmcn1MZp0q3hB6wOrBth98q8gJMduAnfzMsuzO48l/AOB83Mu9YBRd ZQJP5rJfXRifNtRteL+fghTgkVWfOydEhgFJWEAq+vJ7SkaLsJKiwvFYZfL9RT5eVYP6 OAE2QktmwW/4GHEOThfGrqc9CyEJFo7AUnUOih/8Ci4XedwFRe9qcU596DHN10rdI5wq MjFQ==
X-Gm-Message-State: AOAM5314kCRbsTqS/07aJ+bVMqJyQKVFK7LACxC3oAnt/mWupi9UuH8R udRCt5SiVQTyyktl39O8hqDODqrBRooFZX2T4hm/0/hHH3Lg5w==
X-Google-Smtp-Source: ABdhPJwhlDvFCLepBAFrr6zYa2RmTD32GlUbur4Tjn3t98/aePMqoFuvicA0BR7PLh8cedyInyKvu5SrjvZgNS04Ls4=
X-Received: by 2002:a67:ee16:: with SMTP id f22mr9371376vsp.8.1605819384540; Thu, 19 Nov 2020 12:56:24 -0800 (PST)
MIME-Version: 1.0
References: <CAH56bmCkmtvqTRaEC-AFd-_W1nWeE0JE9SMt=w8E5JoHvvnVtQ@mail.gmail.com> <ba17cdbf-e58f-6b35-0bd6-7c9a86089913@gmx.at> <CAKcm_gMdsHt4-_e0hNZC6Nn-TTz+r6LGYt=Mc8N3nTSo9to3nQ@mail.gmail.com> <885d9aa0-50b2-3101-64b8-7a40f25ca612@erg.abdn.ac.uk> <CAH56bmBxY2qMRMFxoeWhq0bd_eV4W-Mvpc3GFKEKY1ZyuOAW_w@mail.gmail.com> <DM6PR00MB06350BB2986E364D2D8DBBDDB6E09@DM6PR00MB0635.namprd00.prod.outlook.com>
In-Reply-To: <DM6PR00MB06350BB2986E364D2D8DBBDDB6E09@DM6PR00MB0635.namprd00.prod.outlook.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 19 Nov 2020 15:56:08 -0500
Message-ID: <CADVnQykmKQHRDu1LZMQ48bEbJ6zn8itxi67Ve_vszw_EK06ytQ@mail.gmail.com>
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Cc: "mattmathis=40google.com@dmarc.ietf.org" <mattmathis=40google.com@dmarc.ietf.org>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "ianswett=40google.com@dmarc.ietf.org" <ianswett=40google.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fdb90f05b47bf5ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0f3LlodVIssS107GBBXUWQWOUxU>
Subject: Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis (Proportional Rate Reduction) as a tcpm work item? INPUT NEEDED
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 20:56:29 -0000
I am very supportive of updating PRR to PS status and adopting this as a TCPM work item. I will be happy to review the document as well. The "Tentative path forward" outlined by Matt sounds good to me. best, neal On Thu, Nov 19, 2020 at 12:37 PM Praveen Balasubramanian <pravb= 40microsoft.com@dmarc.ietf.org> wrote: > I am supportive of updating PRR to PS status and will review the document. > > > > Re. QUIC. The current loss recovery spec for QUIC already refers to PRR as > a MAY and has similar other references to TCP RFCs without any additional > text for QUIC specific adaptations. The current title of RFC 6937 scopes it > to TCP: Proportional Rate Reduction for TCP. I also see about 38 hits for > the word TCP in the text. > > > > *From:* tcpm <tcpm-bounces@ietf.org> *On Behalf Of * Matt Mathis > *Sent:* Thursday, November 19, 2020 8:41 AM > *To:* Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Ian Swett <ianswett= > 40google.com@dmarc.ietf.org> > *Cc:* tcpm@ietf.org Extensions <tcpm@ietf.org> > *Subject:* [EXTERNAL] Re: [tcpm] Introduce RFC 6937 bis (Proportional > Rate Reduction) as a tcpm work item? INPUT NEEDED > > > > If we can get away with a non-normative description of the heuristic, QUIC > is no problem at all. If we need normative descriptions, then TCP and > QUIC have to be different, and we need to include normative references to > both recovery machines and recovery state variables, which are not in scope > for the current doc. > > > > I would prefer to stay with a non-normative description of the heuristic, > and scrub the rest of the document for language that conflicts with QUIC. > > > Thanks, > > --MM-- > The best way to predict the future is to create it. - Alan Kay > > We must not tolerate intolerance; > > however our response must be carefully measured: > > too strong would be hypocritical and risks spiraling out of > control; > > too weak risks being mistaken for tacit approval. > > > > > > On Thu, Nov 19, 2020 at 6:37 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> > wrote: > > On 19/11/2020 14:20, Ian Swett wrote: > > I support this work. > > > > One question for authors and the group. This specification could be > applied to QUIC, but my memory is that there are some small changes to > adapt it correctly. Would noting those changes be in scope for this > document, a separate document in QUIC, or an exercise left to the reader? > I'd be happy to contribute any QUIC specific text if that's helpful. > > > > Thanks, Ian > > I'd hope the differences for QUIC ARE captured in the RFC series. If they > are small, it might be possible to add to this draft perhaps? > > Gorry > > > > On Thu, Nov 19, 2020 at 2:43 AM Scheffenegger, Richard <rs.ietf@gmx.at> > wrote: > > As the heuristic is the one major improvement over RFC6937, that is the > one area I am especially interested in. Currently working to have PRR in > FreeBSD, it would be the best time window to add this heuristig instead > of switching between the two variants in a static fashion. > > I support this and will certainly be reviewing the documents and provide > feedback! > > Richard > > > Am 19.11.2020 um 04:56 schrieb Matt Mathis: > > The authors of PRR would like to update PRR to Proposed Standard > > status. This entails introducing a new document as an tcpm work item. > > > > *Please indicate (non) support and/or comment.* > > > > For more details see the tcpm meeting materials from IETF 109 > > minutes: > > https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-00 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fminutes-109-tcpm-00&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705303486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GotM4AhjDjqbRs6okuMEeAQxQBUmmuNaFhI7grBtQu4%3D&reserved=0> > > slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mathis-tcpm-rfc6937bis-00&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705303486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1I8wixEmKrng%2FqDAzYajQpv85dagIleRdvqCSupoaUQ%3D&reserved=0> > > > > There were about four "I support this work" remarks at the mic (not > > recorded in the minutes), and about as many in the Meetecho chat. > > > > Abridged IETF/tcpm/PRRbis slides: > > -- > > PRR recap (RFC6937 experimental) > > PRR is a special congestion control effective only during fast recovery > > > > * When inflight >= ssthresh, send at loss_beta*rate_before_loss (e.g. > > loss_beta = 0.5 for Reno (aka rate-halving), 0.7 for Cubic) > > * When inflight < ssthresh, send at the same or twice the > > delivery_rate (more later) > > * Used by all congestion control modules in Linux during fast recovery > > o Can be more dominant than the actual C.C. for lossy flows > > that’re in fast recovery constantly (e.g. video streaming > > through policers) > > > > -- > > Current Status > > > > * > > > > PRR is widely deployed > > > > o > > > > At least three major OSs: Linux, Windows, (NetFlix) BSD > > > > o > > > > Vast majority of Web traffic for years > > > > * > > > > No changes to algorithms published in RFC 6937 > > > > o > > > > PRR-CRB - Conservative Reduction Bound - strict packet > > conversion during loss recovery > > > > o > > > > PRR-SSRB - Slowstart Reduction Bound - one extra segment per ACK > > during loss recovery > > > > * > > > > 2015 Heuristic to dynamically select which reduction bound > > > > o > > > > Only use PRR-SSRB when making good forward progress > > > > + > > > > ACKs that advanced snd.una and report no new losses > > > > o > > > > Resolves some pathological cases with token bucket policers > > > > + > > > > CC estimates ssthresh before it can possibly measure the > > token rate > > > > + > > > > The heuristic makes the best of a bad situation > > > > -- > > Tentative path forward > > > > * > > > > Adopt as a tcpm work item > > > > * > > > > Update the text > > > > o > > > > Normative RFC 2119 language > > > > o > > > > Add MAY use the heuristic... > > > > o > > > > Trim redundant and obsolete language > > > > + > > > > RFC 6937 repeats itself and is much longer than necessary > > > > + > > > > Focus on what an implementer needs to know > > > > + > > > > Use non-normative references to RFC 6937 for prior > > measurement work, etc > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > We must not tolerate intolerance; > > however our response must be carefully measured: > > too strong would be hypocritical and risks spiraling out of > > control; > > too weak risks being mistaken for tacit approval. > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705313440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZsMBF3VehUvHSJfggPYbPco34h9UiTG%2BKbyXU1Bz%2BA%3D&reserved=0> > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705313440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZsMBF3VehUvHSJfggPYbPco34h9UiTG%2BKbyXU1Bz%2BA%3D&reserved=0> > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705313440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZsMBF3VehUvHSJfggPYbPco34h9UiTG%2BKbyXU1Bz%2BA%3D&reserved=0> > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705323397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JXlBlyxDMB2qQUlx%2BY44b7fZfgcj8HaDcEAkfAv7AAI%3D&reserved=0> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >
- [tcpm] Introduce RFC 6937 bis (Proportional Rate … Matt Mathis
- Re: [tcpm] Introduce RFC 6937 bis (Proportional R… Scheffenegger, Richard
- Re: [tcpm] Introduce RFC 6937 bis (Proportional R… Ian Swett
- Re: [tcpm] Introduce RFC 6937 bis (Proportional R… Scharf, Michael
- Re: [tcpm] Introduce RFC 6937 bis (Proportional R… Gorry Fairhurst
- Re: [tcpm] Introduce RFC 6937 bis (Proportional R… Matt Mathis
- Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis … Praveen Balasubramanian
- Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis … Neal Cardwell
- Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis … Yuchung Cheng
- [tcpm] Request for feedback on WG Adoption of RFC… Yoshifumi Nishida
- Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis … Martin Duke
- Re: [tcpm] Request for feedback on WG Adoption of… Yoshifumi Nishida
- Re: [tcpm] Request for feedback on WG Adoption of… Yoshifumi Nishida
- Re: [tcpm] Request for feedback on WG Adoption of… Scheffenegger, Richard
- Re: [tcpm] Request for feedback on WG Adoption of… Scheffenegger, Richard