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

[Matt Mathis <[e-mail]>]

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.