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

[Zaheduzzaman Sarker <[e-mail]>]

> On 19 Sep 2022, at 20:49, 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 would like to see the congestion control algorithms are specified generic to both transport protocols and the application uses those transport protocols. The application adaptation of the transport protocol uses (for example- rate adaptation for real-time applications) or transport specific part ( like - HyStart++ for QUIC) is left for the protocols or applications that want to use a particular congestion control algorithm. But that might be tough to achieve because of the way we have been specifying the congestion control algorithms. 

My suggestion here would be take to this case as an individual case and make the best possible decision that will get the HyStart ++ published ASAP. So, the authors and TCPM WG can decide what to do here.    

(Another things is when a RFC gets published it usually don’t have a working group name-tag with it ( except for IANA considerations ), So the discussion that we sometime have that this is done on TCPM but related to other protocols is kind of not that important. It is important that TCMP stick to its charter and continue doing the great job it is already doing!!!)
> 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...
> 
> 
I am actually not worried about this. Every working group runs by their own charter and their own ways of working, every working group has it’s own character. Hence, there might not be complete consistency. On a same consensus call two different working groups may decide to have two different consensus stands. I think that is fine!!

I believe even if we make the congestion control working group a reality, we will still have certain discussions on what should be done where, what is transport protocol and what is not. The good thing will be that then we will have a common platform to discuss and decide on those.

//Zahed