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

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=
40microsoft.com@dmarc.ietf.org> 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 <tcpm-bounces@ietf.org> *On Behalf Of * Matt Mathis
> *Sent:* Thursday, November 19, 2020 8:41 AM
> *To:* Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Ian Swett <ianswett=
> 40google.com@dmarc.ietf.org>
> *Cc:* tcpm@ietf.org Extensions <tcpm@ietf.org>
> *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 <gorry@erg.abdn.ac.uk>
> 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 <rs.ietf@gmx.at>
> 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
> > tcpm@ietf.org
> > 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
> tcpm@ietf.org
> 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
>
> tcpm@ietf.org
>
> 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
> tcpm@ietf.org
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>