Re: [tcpm] Request for feedback on WG Adoption of RFC6937bis

["Scheffenegger, Richard" <[e-mail]>]

FWIW, PRR has been included in FBSD13 as default.

That implementation my be a bit rough at the edges - the particular case
to deal with "broken" token-bucket traffic policers mentioned by Matt
using an automatic heustric is not in, and if encountered, need to be
dealt with manually.


Richard


Am 30.11.2020 um 19:12 schrieb Yoshifumi Nishida:
> 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
> let us know.
>
> Thank you so much,
> --
> Yoshi on behalf of tcpm co-chairs
>
>
> On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis
> <mattmathis=[e-mail]
> <mailto:[e-mail]>> 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
>     <https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-00>
>     slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00
>     <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 >= 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tcpm
>     <https://www.ietf.org/mailman/listinfo/tcpm>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>