Re: [tcpm] Introduce RFC 6937 bis (Proportional Rate Reduction) as a tcpm work item? INPUT NEEDED

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

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 >= 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]
> https://www.ietf.org/mailman/listinfo/tcpm
>