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

> On 19. Sep 2022, at 20:49, Christian Huitema <huitema@huitema.net> wrote:
> 
> 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.
Hi Christian,

several of the specification done in TCPM are not limited to TCP, and this is covered
by the charter. Using RACK, for example, makes a lot of sense for SCTP. However, most
of the specs use a language specific to one transport protocol but you can easily
translate them to the other. So there is some transfer to be made by the reader. The
only alternative I see would be to use a very generic, protocol-agnostic, language,
or deal with a set of protocols (including DCCP, QUIC, SCTP, TCP).

In your particular example of HyStart++, the introduction contains:

While this document describes Hystart++ for TCP, it can also be used for other
transport protocols which use slow start such as QUIC [RFC9002] or SCTP [RFC9260].

And as far as I know, there are implementations of HyStart++ for QUIC. I think
the specification is also clear enough to implement it in SCTP.
> 
> 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?
Do you think QUIC specific text is needed in the document to know how to implement it
for QUIC? If yes, you can still suggest it.

Best regards
Michael
> 
> 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
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm