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

[Gorry Fairhurst <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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://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] <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