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

Hi all,

The TCPM charter also has another sentence:

"The focus of the working group is TCP. In cases where small
changes are directly applicable to other transports (e.g., SCTP or
DCCP), the mappings to other transports may be specified alongside
that for TCP, but other significant additions and changes to other
transports are not in scope."

When this was written, SCTP and DCCP were relevant examples. This text could also apply to an algorithm that applies to TCP and QUIC.

The same applies to a third statement in the TCPM charter:

"In the past, the IETF has worked on several documents about algorithms that
are specified for multiple protocols (e.g., TCP and SCTP) in the
same document. Which WG shepherds such documents will be determined
on a case-by-case basis."

In a nutshell, generic algorithms that apply to TCP and other transports (such as QUIC) can be specified in TCPM within the existing charter - if the community wants to do so. In the past, most implementors of other transports have followed TCPM anyway, and thus this probably was a reasonable approach. The TCPM charter is quite flexible in these cases already.

Quite a bit of the TCPM charter text would probably have to be rephrased if a new congestion control WG was established. In that case, probably not a lot would be left for TCPM as remaining work, as many TCP specs at least partly deal with congestion control.

Michael
(as the last author of TCPM charter wordings)

> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Christian Huitema
> Sent: Monday, September 19, 2022 9:05 PM
> To: Martin Duke <martin.h.duke@gmail.com>
> Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>;
> tcpm@ietf.org Extensions <tcpm@ietf.org>
> Subject: Re: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC
> 
> I followed it from afar. The proposed charter is fine, but I don't see
> much progress towards an actual WG. It seems that these discussions are
> de-factor happening in TCPM. Indeed, the TCPM charter says: "TCPM also
> provides a venue for standardization of incremental enhancements of
> TCP's standard congestion control. In addition, TCPM may document
> alternative TCP congestion control algorithms that are known to be
> widely deployed, and that are considered safe for large-scale deployment
> in the Internet."
> 
> -- Christian Huitema
> 
> On 9/19/2022 11:52 AM, Martin Duke wrote:
> > 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
> <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.
> >>
> >> 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
> >>
> >>
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm