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

[Yoshifumi Nishida <[e-mail]>]

Hello everyone,
This is just a reminder in case you forgot to express your opinion on this.
We'll make a decision soon.

Thanks,
--
Yoshi on behalf of tcpm co-chairs

On Mon, Nov 30, 2020 at 10:12 AM Yoshifumi Nishida <[e-mail]>
wrote:

> 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]> 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
>> 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
>>       - 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
>>    -
>>
>>       At least three major OSs: Linux, Windows, (NetFlix) BSD
>>       -
>>
>>       Vast majority of Web traffic for years
>>       -
>>
>>    No changes to algorithms published in RFC 6937
>>    -
>>
>>       PRR-CRB - Conservative Reduction Bound - strict packet conversion
>>       during loss recovery
>>       -
>>
>>       PRR-SSRB - Slowstart Reduction Bound - one extra segment per ACK
>>       during loss recovery
>>       -
>>
>>    2015 Heuristic to dynamically select which reduction bound
>>    -
>>
>>       Only use PRR-SSRB when making good forward progress
>>       -
>>
>>          ACKs that advanced snd.una and report no new losses
>>          -
>>
>>       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
>>    -
>>
>>       Normative RFC 2119 language
>>       -
>>
>>       Add MAY use the heuristic...
>>       -
>>
>>       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
>>
>