Re: [tcpm] volunteers to draft QUIC-related text for draft-ietf-tcpm-prr-rfc6937bis?

[Christian Huitema <[e-mail]>]

On 8/27/2024 8:47 AM, Neal Cardwell wrote:
> This is a quick note to see if there is interest in suggesting QUIC-related
> text for draft-ietf-tcpm-prr-rfc6937bis, "Proportional Rate Reduction for
> TCP":
>    https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/
>
> At TCPM at IETF 120 in July, there were a few people suggesting that it
> would be nice if the prr-rfc6937bis draft had a section explaining how PRR
> could be implemented for QUIC. Here's the discussion, if you are curious
> about the context:
>    https://www.youtube.com/watch?v=eF_Qa475ag8&t=2553s
>
> Are there any folks with QUIC implementation experience who are interested
> in volunteering to write a few paragraphs for the prr-rfc6937bis draft to
> add a section explaining how PRR could be implemented for QUIC?

Maybe the urgency is not that big. The text in RFC 9002 says:

Implementations MAY reduce the congestion window immediately upon 
entering a recovery period or use other mechanisms, such as Proportional 
Rate Reduction [PRR <https://www.rfc-editor.org/rfc/rfc9002.html#PRR>], 
to reduce the congestion window more gradually. If the congestion window 
is reduced immediately, a single packet can be sent prior to reduction. 
This speeds up loss recovery if the data in the lost packet is 
retransmitted and is similar to TCP as described in Section 5 
<https://www.rfc-editor.org/rfc/rfc6675#section-5> of [RFC6675 
<https://www.rfc-editor.org/rfc/rfc9002.html#RFC6675>]. So, it is a MAY, 
with an informational reference. As weak a claim as you can make it.

Moreover, many implementers take RFC 9002 (QUIC RECOVERY) with a grain 
of salt. The loss recovery part is fine, but the congestion control part 
is an adaptation of Reno, because the WG charter stated that only Reno 
would be considered. Some implementations do support Reno as an option, 
but most deployments use Cubic or BBR. For those, the only mandate that 
apply are those in RFC 9000, which are very generic. In the section 1, 
Overview, we find: "QUIC depends on congestion control to avoid network 
congestion. An exemplary congestion control algorithm is described in 
Section 7 <https://www.rfc-editor.org/rfc/rfc9002#section-7> of 
[QUIC-RECOVERY 
<https://www.rfc-editor.org/rfc/rfc9000.html#QUIC-RECOVERY>]". Section 
9.4 specifies that when multiple paths are used, congestion control is 
"per path"; that requirement is kept in the QUIC multipath expension draft.

There are a couple of complicating factors. First, while loss detection 
is rather similar to TCP, retransmission and flow control are very 
different: QUIC can send data on several parallel streams, different 
flow control variables apply per stream and globally, and retransmission 
operates at the frame level, not the packet level. Different streams may 
have different priorities, and those priorities also affect which data 
is repeated first -- or maybe not repeated at all.

Then there are the differences between implementation in the kernel, 
like TCP, and implementations in a user process, like QUIC. Some things 
are easier, such as managing memory or handling fine grained timers. 
Other are most costly, in particular sending packets through the socket 
API, which leads to desire to use features like GSO or sendmmsg and send 
packets in batches.

To come back to PRR, the main reference in RFC 9000 is in section 4.2. 
on flow control limits, which says "When a sender receives credit after 
being blocked, it might be able to send a large amount of data in 
response, resulting in short-term congestion; see Section 7.7 
<https://www.rfc-editor.org/rfc/rfc9002#section-7.7> of [QUIC-RECOVERY 
<https://www.rfc-editor.org/rfc/rfc9000.html#QUIC-RECOVERY>] for a 
discussion of how a sender can avoid this congestion." Different 
implementations may treat that problem differently. The general 
agreement is to do some form of pacing.

The implementation that I maintain uses a leaky-bucket style pacing, in 
which the size of the bucket allows for sending reasonable batches of 
packet, and the rate of the bucket matches a pacing rate either computed 
directly (e.g., with BBR) or derived from Congestion Window size and RTT 
(e.g., for Cubic and Reno). Other implementations make their own 
choices. AFAIK, there is no big demand inside the QUIC WG to standardize 
that.

> There was also a suggestion (sensible, IMHO) to set a two-month timeout,
> and ship the draft without QUIC text if we don't get a contribution before
> then. And that was a little over one month ago, so let's set a timeout of
> one month from now: Sep 27th. If we get a contribution of a QUIC section by
> Sep 27th, 2024 (any time zone) then we'll add that to the draft. Otherwise,
> I think the consensus was to try to progress without a QUIC section.

That seems very reasonable. The TCPM group should publish a TCP related 
specification. If it does replace RFC6937, QUIC developers will read it 
instead of or in addition to the RFC6937 reference of RFC 9002.

-- Christian Huitema