From nobody Thu Nov 19 06:21:08 2020 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 C02603A107E for ; Thu, 19 Nov 2020 06:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, 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=ham 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 VL6F0yeUgymk for ; Thu, 19 Nov 2020 06:21:02 -0800 (PST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 216EB3A1075 for ; Thu, 19 Nov 2020 06:21:02 -0800 (PST) Received: by mail-yb1-xb2e.google.com with SMTP id g15so5334599ybq.6 for ; Thu, 19 Nov 2020 06:21:02 -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=5Mtgg0ZeCH0GEQ6sJFLr3gl3PrthcMRPfOJiQQu+760=; b=bPJZbbos6OlR/CaBOH/A1BSvCHJS63gj67m/516PJtBJ+umpDgtFxe/4EfVmI/ewUD +kgzyPboyiCfVrUx4mf48SMhCx5RdasjSATJgWmzPmgjaMLTmLF7v2b/VHqTne/sU/7o ofUcm804fOFBi1AJGsElzRuA9X1JMewvHBolJfz58vcrqkCHnNFgUqhlD1Xz8y1lXop4 LvrTmWY61GsLm8pkM3atXqn/tKyQYBaE7/6J84KfyBV7DMlzygvFWd9poUski9i+242/ +ZXy423eZqyJces2tSghzxIsyRUdSIWz3gslQw0dBUQ1kAP52Muta4sG7RQ1UqtueFZZ LmtA== 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=5Mtgg0ZeCH0GEQ6sJFLr3gl3PrthcMRPfOJiQQu+760=; b=NrV8ZJ+JyAmPB2Tm2Ls7nBwqIj676Hs3p6eShU9yLJPAIbD6eBceYSCHDVPBEiQrhp 0iFu30Nihe5ldS7mhOgi7RFsuir9AZYpnaU/N9cauGZrqtDQqleROK1StEiI+gyfEl80 oe1K7jqha/2rjHXFFq9N45HneaWVNp/5jDsAF/G+cgYV91e0gtE1IsD4Dy9Q/9FkSK7M iroImBDrZ8ooq0qS11z9DxCJoZZ26Y9gB/TM126oKfHLdWFKsxTDJpLTw9w8FL321Ml5 8+YGo0i/MJ8y1gf5Qr+Z7DP76hHVpLpZ428aHSQGduxl5nEwWBvPtkNu3aGD7z8BNrtL z1jg== X-Gm-Message-State: AOAM532DSlhgYiESfF0jwQhcTb/dVQFIiYKoKoSKPw//QotkzZMRAMW6 tq1mt66/8bkBX8PGdLiO+KEzksnu8/BtUm0AC6GLig== X-Google-Smtp-Source: ABdhPJxvhTL8eAn4QX+LAkDPJ61BR1QefUYnES+qhsiyghj3POZjOuktUYrKnPkK8JaKO9BC9NOyiF/RCRP/0+Baqc0= X-Received: by 2002:a25:3448:: with SMTP id b69mr14095414yba.77.1605795661014; Thu, 19 Nov 2020 06:21:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Thu, 19 Nov 2020 09:20:49 -0500 Message-ID: To: "Scheffenegger, Richard" Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000f5961405b4766f77" Archived-At: Subject: Re: [tcpm] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:21:07 -0000 --000000000000f5961405b4766f77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Thu, Nov 19, 2020 at 2:43 AM Scheffenegger, Richard 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 > > 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 > > o Can be more dominant than the actual C.C. for lossy flows > > that=E2=80=99re in fast recovery constantly (e.g. video streami= ng > > 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 AC= K > > 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 o= f > > control; > > too weak risks being mistaken for tacit approval. > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000f5961405b4766f77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support this work.

One question for a= uthors and the group.=C2=A0 This specification=C2=A0could be applied to QUI= C, but my memory is that there are some small changes to adapt it correctly= .=C2=A0 Would noting those changes be in scope for this document, a separat= e document in QUIC, or an exercise left to the reader?=C2=A0 I'd be hap= py to contribute any QUIC specific text if that's helpful.
Thanks, Ian

On Thu, Nov 19, 2020 at 2:43 AM Scheffenegger= , Richard <rs.ietf@gmx.at> wrot= e:
As the heuris= tic 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.=C2=A0 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 m= ic (not
> recorded in the minutes), and about as many in the Meetecho chat.
>
> Abridged IETF/tcpm/PRRbis slides:
> --
> PRR =C2=A0recap (RFC6937 experimental)
> PRR is a special congestion control effective only during fast recover= y
>
>=C2=A0 =C2=A0* When inflight >=3D ssthresh, send at loss_beta*rate_b= efore_loss (e.g.
>=C2=A0 =C2=A0 =C2=A0loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 = for Cubic)
>=C2=A0 =C2=A0* When inflight < ssthresh, send at the same or twice t= he
>=C2=A0 =C2=A0 =C2=A0delivery_rate (more later)
>=C2=A0 =C2=A0* Used by all congestion control modules in Linux during f= ast recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o Can be more dominant than the actual C.C. = for lossy flows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that=E2=80=99re in fast recovery cons= tantly (e.g. video streaming
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0through policers)
>
> --
> Current Status
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0PRR is widely deployed
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At least three major OSs: Linux, Wind= ows, (NetFlix) BSD
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vast majority of Web traffic for year= s
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0No changes to algorithms published in RFC 6937
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRR-CRB - Conservative Reduction Boun= d - strict packet
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0conversion during loss recovery
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRR-SSRB - Slowstart Reduction Bound = - one extra segment per ACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0during loss recovery
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A02015 Heuristic to dynamically select which reductio= n bound
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Only use PRR-SSRB when making good fo= rward progress
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACKs that advanced snd.= una and report no new losses
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resolves some pathological cases with= token bucket policers
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CC estimates ssthresh b= efore it can possibly measure the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token rate
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The heuristic makes the= best of a bad situation
>
> --
> Tentative path forward
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0Adopt as a tcpm work item
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0Update the text
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Normative RFC 2119 language
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Add MAY use the heuristic...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Trim redundant and obsolete language<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6937 repeats itself= and is much longer than necessary
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Focus on what an implem= enter needs to know
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Use non-normative refer= ences to RFC 6937 for prior
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0measurement 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=A0 =C2=A0however our response must be carefull= y measured:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hy= pocritical and risks spiraling out of
> control;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being m= istaken for tacit approval.
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000f5961405b4766f77--