[tcpm] draft-ietf-tcpm-hystartplusplus and QUIC

[Christian Huitema <[e-mail]>]

I have followed the progress of the Hystart++ draft in TCPM, and I have 
a process question.

Algorithms like Hystart++ are not just used by TCP, but also by other 
protocols like QUIC. They are developed in the "TCP maintenance" WG, 
which is indeed about TCP, and thus the spec is quite TCP centric. For 
example, in the definition section of draft-ietf-tcpm-hystartplusplus, 
we read that "if the MSS option is not used, [the receiver maximum 
segment size] is 536 bytes" -- but "QUIC assumes a minimum IP packet 
size of at least 1280 bytes" per RFC9000. Which leads to the process 
question.

Should congestion control algorithm be specified in a transport protocol 
specific way, as for example "HyStart++ for QUIC", or should the 
specification be kept as generic as possible?

I can absolutely see valid reasons for doing either way. Having generic 
specification means doing the work just once, also help achieving 
somewhat compatible behavior by multiple transport protocols. Having 
transport specific specifications leads to more precise specification -- 
HyStart++ for QUIC can reference the correct minimum packet size, the 
negotiation of "max_udp_payload_size", or the interaction with 
draft-ietf-quic-ack-frequency.

The QUIC WG recently had an adoption call of a draft specifying "Careful 
resumption of congestion control from retained state with QUIC". The 
adoption was refused. To quote, "The chairs' sense of the feedback is 
that while this is useful work that people support at the IETF, it is 
work in a problem space is more broadly to do with congestion control 
and not entirely QUIC specific." The authors were instructed to work 
with tsvwg, or with a to-be-formed congestion control WG. So we see two 
discussions with opposite conclusions: HyStart++ adopted in TCPM, 
careful resumption redirected to a generic WG.

I wish there was a consistent approach...

-- Christian Huitema