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

[Yoshifumi Nishida <[e-mail]>]

Happy new year everyone,

Sorry for taking long time.
Based on the feedback we've received, we've concluded the rough consensus
of the WG is that this document should be adopted as a WG item for a PS
document.
So, after some discussions with the authors, we plan to set the following
milestone for this draft.

   Aug 2021     Submit document on RFC6937bis to IESG for publication as a
Proposed Standard RFC

We appreciate your cooperations!
Please let us know you have any questions or comments .
--
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
>>
>