Re: [tcpm] New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt

["Scharf, Michael" <[e-mail]>]

> > How about use beyond
> > TCP, e.g., would a syncing with the QUIC WG make sense (you may actually
> have
> > a better understanding on that than me)?
> 
> We have https://github.com/NTAP/rfc8312bis/issues/45 open for that. It not
> clear at this time whether any additional text is needed to explain more
> about how QUIC would use CUBIC, a bunch of changes were made already to
> this purpose.

The chair-ish question is whether the QUIC WG needs to be in the loop in a more formal way. The TCPM charter states:

<snip>
TCP's congestion control algorithms are the model followed by
other IETF transports (e.g., SCTP or DCCP), which are standardized in
other working groups, such as the Transport Area WG (tsvwg). 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 any case, the TCPM WG will remain in
close contact with other relevant WGs working on these protocols to
ensure openness and stringent review from all angles.
</snip>

In other related cases, TCPM has decided during WG adoption to run a joint WGLC with TSVWG. We could decide to do something similarly in this case, e.g., a joint WGLC with the QUIC WG. That is something that would probably have to be agreed upon in the TCPM adoption call. But I am unsure; the expertise may be in the TCPM community anyway... Please feel free to chime in...

> > And are there any TCP RFCs that
> > assume that only a single standard congestion control exist and that would
> > perhaps have to be updated?
> 
> I'm sure there are a bunch of TCP specs that only cite NewReno, but that's
> probably OK? I'm not sure if finding and updating them just to say "you may
> also use CUBIC" is all that worthwhile. Also, we didn't do this for 8312 (or any
> other experimental/informational CC scheme) so it's not clear why we'd do
> so for 8312bis.

The new congestion control text in 793bis probably helps here. Maybe the wording in 793bis is just sufficient. But I haven't looked at the details. I guess a lot of old text was written under the assumption that there is *one* standard congestion control algorithm only. Unlike earlier CC schemes, 8312bis on standards track changes that. Now we have at leas two. It would be better to understand the implications early.

Michael