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

[Matt Mathis <[e-mail]>]

If we can get away with a non-normative description of the heuristic, QUIC
is no problem at all.    If we need normative descriptions, then TCP and
QUIC have to be different, and we need to include normative references to
both recovery machines and recovery state variables, which are not in scope
for the current doc.

I would prefer to stay with a non-normative description of the heuristic,
and scrub the rest of the document for language that conflicts with QUIC.

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.


On Thu, Nov 19, 2020 at 6:37 AM Gorry Fairhurst <[e-mail]>
wrote:

> 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]>
> 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 >= 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
>> >
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
> _______________________________________________
> tcpm mailing [e-mail]://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>