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

[Martin Duke <[e-mail]>]

I am definitely in favor of taking widely-adopted Experimental documents
and updating/upgrading them, including this one.

On Fri, Nov 20, 2020 at 12:52 PM Yuchung Cheng <ycheng=
[e-mail]> wrote:

> Thanks for everybody's reply and support
>
> One additional thing we authors would like more feedback on is ECN. The
> current RFC and proposed -bis do not cover ECN handling. However in Linux,
> ECN handling uses the same PRR algorithm (aka "CWR" aka "cwnd reduction")
> just like fast recovery. In other words, if RFC3168 or DCTCP triggers a
> congestion window reduction, PRR takes over to control the transmission
> until SND_UNA crosses SND.NXT upon reduction.
>
> This arrangement was inherented from the original Linux rate-halving
> design before the PRR was introduced. This paper has details
> https://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf
>
> Compared to fast recovery, this part of the implementation is far less
> tested due to the lack of wide classic-ECN usage on the Internet. It's also
> unclear how other PRR implementations have applied to ECN handling like
> Linux does. Adding ECN handling in -bis PS makes me uneasy.
>
> On Thu, Nov 19, 2020 at 12:57 PM Neal Cardwell <ncardwell=
> [e-mail]> wrote:
>
>> I am very supportive of updating PRR to PS status and adopting this as a
>> TCPM work item. I will be happy to review the document as well.
>>
>> The "Tentative path forward" outlined by Matt sounds good to me.
>>
>> best,
>> neal
>>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 12:37 PM Praveen Balasubramanian <pravb=
>> [e-mail]> wrote:
>>
>>> I am supportive of updating PRR to PS status and will review the
>>> document.
>>>
>>>
>>>
>>> Re. QUIC. The current loss recovery spec for QUIC already refers to PRR
>>> as a MAY and has similar other references to TCP RFCs without any
>>> additional text for QUIC specific adaptations. The current title of RFC
>>> 6937 scopes it to TCP: Proportional Rate Reduction for TCP. I also see
>>> about 38 hits for the word TCP in the text.
>>>
>>>
>>>
>>> *From:* tcpm <[e-mail]> *On Behalf Of * Matt Mathis
>>> *Sent:* Thursday, November 19, 2020 8:41 AM
>>> *To:* Gorry Fairhurst <[e-mail]>; Ian Swett <ianswett=
>>> [e-mail]>
>>> *Cc:* [e-mail] Extensions <[e-mail]>
>>> *Subject:* [EXTERNAL] Re: [tcpm] Introduce RFC 6937 bis (Proportional
>>> Rate Reduction) as a tcpm work item? INPUT NEEDED
>>>
>>>
>>>
>>> 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
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F109%2Fmaterials%2Fminutes-109-tcpm-00&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705303486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GotM4AhjDjqbRs6okuMEeAQxQBUmmuNaFhI7grBtQu4%3D&reserved=0>
>>> > slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mathis-tcpm-rfc6937bis-00&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705303486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1I8wixEmKrng%2FqDAzYajQpv85dagIleRdvqCSupoaUQ%3D&reserved=0>
>>> >
>>> > 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
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705313440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZsMBF3VehUvHSJfggPYbPco34h9UiTG%2BKbyXU1Bz%2BA%3D&reserved=0>
>>> >
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705313440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZsMBF3VehUvHSJfggPYbPco34h9UiTG%2BKbyXU1Bz%2BA%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> tcpm mailing list
>>>
>>> [e-mail]
>>>
>>> https://www.ietf.org/mailman/listinfo/tcpm <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705313440%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZsMBF3VehUvHSJfggPYbPco34h9UiTG%2BKbyXU1Bz%2BA%3D&reserved=0>
>>>
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=04%7C01%7Cpravb%40microsoft.com%7Cc95254bcba0f41c14f3608d88ca9eac5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637414008705323397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JXlBlyxDMB2qQUlx%2BY44b7fZfgcj8HaDcEAkfAv7AAI%3D&reserved=0>
>>>
>>> _______________________________________________
>>> 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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>