From nobody Mon Jan 4 21:51:54 2021 Return-Path: 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 21E033A1031; Mon, 4 Jan 2021 21:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 byHjceOATwzn; Mon, 4 Jan 2021 21:51:51 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 C542E3A102E; Mon, 4 Jan 2021 21:51:50 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id w79so25635768qkb.5; Mon, 04 Jan 2021 21:51:50 -0800 (PST) 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; bh=RAF6Zl6wwaPhK4b14x00ObV4H4qzmusrZzlHzeW6Lvk=; b=JdThoxsqSU/oVLth7Qizu2jf4MDT14pfFyGOsixy0riIKDnhEnSEMgafvn/GjWAbTc jI1jfDic4JjSmWrGqOZst/rwDO83wo7ed4TOaefgfqgal1NRhcMgYNAkuRjOXyCM1FM1 NCsX0DHZYp0ICdsWaTbq77KoTmzwlbDPYeAhvoSGFgi7Nazcg90wXalBPbKzXakBYV/B oufSles5maYz465qfHMdXqxxIfYlMjTTCOb5YCury16N8oY13Orvivrv8HyKdYYdWOaQ eZPIiyHP+PhvkxetXjTMobW1qei/CklmL8qc2k7saici160niOhlLSEvyxTA4B31yty0 uHVg== 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=RAF6Zl6wwaPhK4b14x00ObV4H4qzmusrZzlHzeW6Lvk=; b=GMn+UQaeJH59NZB554j4raI2V8G882Nx9Mg4TyWOq6y9FrN0iiYoSQ3Lor2p4w85Hg rBaaFMt6t9ekjJ0/IUMf2CTUHPj6Ql1OlO/zHWP/oHHx3U0tJ+Ia3q98D4SdNxjfQTbd oSSjOliyfCvOcNuaTdvaInRxTrIKjHB7JaLWujVzCToWgHP3nUDTA0V/wVD9tfTZI4Tz jO1IYSAUy8k7DuB6HYkkNSrIMOJPVjwSeHvuDm8uZoRarftv7Pg/ugmFltRMfhm8a0EB NloUrTt/kAIm7B2M9M8LBzL8uvC7x4tCgY76Mqn9wGWWNX32pfXfKOnHvwIPSvMksarE 6Bcw== X-Gm-Message-State: AOAM532AXAB0FryJyWtfiTxShNXFumJGnRld6FA5WEN2wONAw7zSQ6Dg h9GucoLQEabJu4HH1SzxJBMVnCbkMQDYzfR0UbrdJT8m X-Google-Smtp-Source: ABdhPJysl6+7KVceMjSanP3clmQz8v5J7Lnga5WXueZ3jpbvPqF1yjaNI8E0nTzZViGo0tG2e1e36xbYygbFre/WDvg= X-Received: by 2002:a05:620a:1279:: with SMTP id b25mr74273948qkl.8.1609825909482; Mon, 04 Jan 2021 21:51:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Mon, 4 Jan 2021 21:51:38 -0800 Message-ID: To: tcpm IETF list Cc: tcpm-chairs Content-Type: multipart/alternative; boundary="0000000000007c292505b820cdbf" Archived-At: Subject: Re: [tcpm] Request for feedback on WG Adoption of RFC6937bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 05:51:53 -0000 --0000000000007c292505b820cdbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Happy new year everyone, Sorry for taking long time. Based on the feedback we've received, we've concluded the rough consensus of the WG is that this document should be adopted as a WG item for a PS document. So, after some discussions with the authors, we plan to set the following milestone for this draft. Aug 2021 Submit document on RFC6937bis to IESG for publication as a Proposed Standard RFC We appreciate your cooperations! Please let us know you have any questions or comments . -- Yoshi on behalf of tcpm co-chairs On Mon, Nov 30, 2020 at 10:12 AM Yoshifumi Nishida wrote: > Hi folks, > > This mail starts a WG adoption call for RFC6937bis draft. > As we've already seen positive supports for this work, we are not asking > people who already expressed their opinions this time. (but, if you want = to > do it for some reason, please go ahead) > However, if you haven't done it yet, especially if you're against it, we > would like to encourage you to provide feedback. > > We are thinking that the intended status of the doc will be PS based on > the feedback we've seen so far. But, if you have opinions on it, please l= et > us know. > > Thank you so much, > -- > Yoshi on behalf of tcpm co-chairs > > > On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis 40google.com@dmarc.ietf.org> wrote: > >> 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 >> slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 >> >> 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 >=3D ssthresh, send at loss_beta*rate_before_loss (e.= g. >> loss_beta =3D 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 recover= y >> - Can be more dominant than the actual C.C. for lossy flows >> that=E2=80=99re in fast recovery constantly (e.g. video streaming = through policers) >> >> -- >> Current Status >> >> - >> >> PRR is widely deployed >> - >> >> At least three major OSs: Linux, Windows, (NetFlix) BSD >> - >> >> Vast majority of Web traffic for years >> - >> >> No changes to algorithms published in RFC 6937 >> - >> >> PRR-CRB - Conservative Reduction Bound - strict packet conversion >> during loss recovery >> - >> >> PRR-SSRB - Slowstart Reduction Bound - one extra segment per ACK >> during loss recovery >> - >> >> 2015 Heuristic to dynamically select which reduction bound >> - >> >> Only use PRR-SSRB when making good forward progress >> - >> >> ACKs that advanced snd.una and report no new losses >> - >> >> 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 >> - >> >> Normative RFC 2119 language >> - >> >> Add MAY use the heuristic... >> - >> >> 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 >> > --0000000000007c292505b820cdbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Happy new year everyone,
<= br>
Sorry for taking long time.=C2= =A0
Based on the feedback we'v= e received, we've concluded the rough consensus of the WG is that this = document should be adopted as a WG item for a PS document.
So, after some discussions with the authors, we plan to set the following = milestone for this draft.

=C2=A0 =C2=A0Aug 2021=C2= =A0 =C2=A0 =C2=A0Submit document on RFC6937bis to IESG for publication as a= Proposed Standard RFC

We appreciate your coop= erations!=C2=A0
Please let us know you have any questions or comm= ents .
--
=
Yoshi on behalf of tcpm co-chairs
=

On Mon, Nov 30, 2020 at 10:12 AM Yoshifumi Nishida <nsd.ietf@gmail.com>= wrote:
Hi folks,

This mail starts a WG adop= tion call for RFC6937bis draft.
As we've already seen positiv= e supports for this work, we are not asking people who already expressed th= eir opinions this time. (but, if you want to do it for some reason, please = go ahead)=C2=A0
However, if you haven't done it yet, especial= ly if you're against it, we would like to encourage you to provide feed= back.

We are thinking that the intended status of = the doc will be PS based on the feedback we've seen so far. But, if you= have opinions on it, please let us know.

Thank yo= u so much,
--
Yoshi on behalf of tcpm co-chairs


On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis <mattmathis=3D40google.com@dmar= c.ietf.org> wrote:
The authors of PRR= would like to update PRR to Proposed Standard status.=C2=A0 This entails i= ntroducing a new document as an tcpm work item.

Please indic= ate (non) support and/or comment.

For more details see the = tcpm meeting materials from IETF 109
slides:=C2=A0https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00

There were about four "I support this work&= quot; remarks at the mic (not recorded in the minutes), and about as many i= n the Meetecho chat.

Abrid= ged IETF/tcpm/PRRbis slides:
--
PRR =C2=A0recap (RFC6937 experimenta= l)
PRR is a special congestion= control effective only during fast recovery
  • When inflight >=3D ssthresh, send at loss_beta*rate_before_= loss (e.g. loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cubic)
  • When inflight < ssthresh, send at t= he same or twice the delivery_rate (more later)
  • Used by all congestion control modules in Linux during fast re= covery
    • Can be more dominant than= the actual C.C. for lossy flows that=E2=80=99re in fast recovery constantl= y (e.g. video streaming through policers)
--
Current Status
=

  • PRR is widely deployed

    • At least thr= ee major OSs: Linux, Windows, (NetFlix) BSD

    • Vast majority of Web traffic for years

  • No changes to algorithms published in RFC 6937

    • = PRR-CRB - Conservative Reduction Bound - strict packet conversion during lo= ss recovery=C2=A0

    • PRR-SSRB - Slowst= art Reduction Bound - one extra segment per ACK during loss recovery=

  • 2015 Heuristic to dynamically select w= hich reduction bound

    • Only use PRR-SSRB when making good forward= progress

        • ACKs that advanced snd.una and report no new losses

    • Resolves some pathological case= s with token bucket policers

      • CC estimates ssthresh before it ca= n possibly measure the token rate

      • = The heuristic makes the best of a bad situation

    --
Tentative path = forward= =C2=A0

  • Adopt as a tcpm work item

  • Update the text

    • Normati= ve RFC 2119 language

    • Add MAY use the heuristic...

    • 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 f= or prior measurement work, etc

=
Thanks,
--MM--
The best way to predict the future is to create it. = =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our = response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypo= critical and risks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being= mistaken for tacit approval.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000007c292505b820cdbf--