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

[Martin Duke <[e-mail]>]

Christian,

Did you track my congestion control working group proposal in tsvarea?

https://github.com/martinduke/congestion-control-charter

This was well received but is currently no one is stepping up to nail down
consensus on the charter.

On Mon, Sep 19, 2022 at 11:50 AM Christian Huitema <[e-mail]>
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.
>
> 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
>
>