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

From: Lars Eggert <[email-masked]>
Date: Mon, 22 Feb 2021 10:54:31 +0200

Hi,

we just submitted the -02 version of the CUBIC bis document.

This version incorporates the major editorial changes we wanted to make.

We'd like to ask the WG to determine if this is ready for adoption. Vidhi has asked for a presentation slot during IETF-110 for this ID, but the adoption discussion IMO doesn't need to wait.

Thanks,
Lars

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-eggert-tcpm-rfc8312bis-02.txt
> Date: February 22, 2021 at 10:49:39 GMT+2
> To: "Injong Rhee" <[email-masked]>, "Lars Eggert" <[email-masked]>, "Lisong Xu" <[email-masked]>, "Sangtae Ha" <[email-masked]>, "Vidhi Goel" <[email-masked]>
> 
> 
> A new version of I-D, draft-eggert-tcpm-rfc8312bis-02.txt
> has been successfully submitted by Lars Eggert and posted to the
> IETF repository.
> 
> Name:		draft-eggert-tcpm-rfc8312bis
> Revision:	02
> Title:		CUBIC for Fast and Long-Distance Networks
> Document date:	2021-02-22
> Group:		Individual Submission
> Pages:		27
> URL:            https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/
> Html:           https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html
> Htmlized:       https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-eggert-tcpm-rfc8312bis-02
> 
> Abstract:
>   CUBIC is an extension to the traditional TCP standards.  It differs
>   from the traditional TCP standards only in the congestion control
>   algorithm on the sender side.  In particular, it uses a cubic
>   function instead of a linear window increase function of the
>   traditional TCP standards to improve scalability and stability under
>   fast and long-distance networks.  CUBIC has been adopted as the
>   default TCP congestion control algorithm by Linux, Windows, and Apple
>   stacks.
> 
>   This document updates the specification of CUBIC to include
>   algorithmic improvements based on these implementations and recent
>   academic work.  Based on the extensive deployment experience with
>   CUBIC, it also moves the specification to the Standards Track,
>   obsoleting [RFC8312].
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 22 Feb 2021 11:20:11 +0100

I am absolutely in favor to adopt this draft.

Like in the recent example of PRR (6937bis), I would like to see that
widely deployed mechanisms are also reflected by a standards-track RFC,
not only experimental.

Richard

Am 22.02.2021 um 09:54 schrieb Lars Eggert:
> We'd like to ask the WG to determine if this is ready for adoption.
> Vidhi has asked for a presentation slot during IETF-110 for this ID, but
> the adoption discussion IMO doesn't need to wait.
>
> Thanks,
> Lars
>
>
>> Begin forwarded message:
>>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for
>> draft-eggert-tcpm-rfc8312bis-02.txt*
>> *Date: *February 22, 2021 at 10:49:39 GMT+2
>> *To: *"Injong Rhee" <[email-masked]
>> <mailto:[email-masked]>>, "Lars Eggert" <[email-masked]
>> <mailto:[email-masked]>>, "Lisong Xu" <[email-masked]
>> <mailto:[email-masked]>>, "Sangtae Ha" <[email-masked]
>> <mailto:[email-masked]>>, "Vidhi Goel" <[email-masked]
>> <mailto:[email-masked]>>
>>
>>
>> Name:draft-eggert-tcpm-rfc8312bis
>> Revision:02
>> Title:CUBIC for Fast and Long-Distance Networks
>> Document date:2021-02-22
>> Group:Individual Submission
>> Pages:27
>> URL:
>> https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt
>> <https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.txt>
>> <https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/>
>> Html:
>> https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html
>> <https://www.ietf.org/archive/id/draft-eggert-tcpm-rfc8312bis-02.html>
>> <https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02>
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-eggert-tcpm-rfc8312bis-02
>> <https://www.ietf.org/rfcdiff?url2=draft-eggert-tcpm-rfc8312bis-02>
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Neal Cardwell <[email-masked]>
Date: Mon, 22 Feb 2021 10:15:52 -0500

I also support WG adoption for this draft; this has some important updates
relative to RFC8312.

best,
neal

---

From: Lars Eggert <[email-masked]>
Date: Mon, 22 Feb 2021 17:57:46 +0200

> widely deployed mechanisms are also reflected by a standards-track RFC,

Agreed, and we are targeting this for PS at the moment for this reason (whether the community agrees with this remains to be seen).

Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Feb 2021 15:30:50 +0200

Hi,

> We'd like to ask the WG to determine if this is ready for adoption.

would a WG chair please acknowledge the request and let us know whether an adoption call will be done?

Thanks,
Lars

---

From: Pete Heist <[email-masked]>
Date: Wed, 24 Feb 2021 15:04:02 +0100

I would support adoption of this draft. It should help to have
documentation for a CCA that's been in active use for so many years,
not least to support related CC work.

Regards,
Pete

On Mon, 2021-02-22 at 10:54 +0200, Lars Eggert wrote:
> Vidhi has asked for a presentation slot during IETF-110 for this ID,
> but the adoption discussion IMO doesn't need to wait.
> 
> Thanks,
> Lars
> 
> 
> > Begin forwarded message:
> > 
> > To: "Injong Rhee" <[email-masked]>, "Lars Eggert"
> > <[email-masked]>, "Lisong Xu" <[email-masked]>, "Sangtae Ha"
> > <[email-masked]>, "Vidhi Goel" <[email-masked]>
> > 
> > 
> > Status:
> >         https://datatracker.ietf.org/doc/draft-eggert-tcpm-rfc8312bis/
> > Html:
> > Htmlized:
> >       https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-02
> > Diff:

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 24 Feb 2021 18:14:32 +0400

I also support moving this document forward.

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 24 Feb 2021 19:00:52 +0200

> On 22 Feb, 2021, at 5:57 pm, Lars Eggert <[email-masked]> wrote:
> 

I support adoption on this basis, and look forward to the review process.

 - Jonathan Morton

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 24 Feb 2021 18:47:50 +0000

Hi Lars,

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of Lars Eggert
> Sent: Wednesday, February 24, 2021 2:31 PM
> To: tcpm IETF list <[email-masked]>
> Subject: Re: [tcpm] New Version Notification for
> draft-eggert-tcpm-rfc8312bis-
> 02.txt
>
> Hi,
>

The chairs will get back - obviously. However, the DelACK principle should not 
be a big surprise ;-)

Until the DelACK timer expires, three foods for thought:

1/ Version -02 was submitted 2 days ago and at least I *always* read drafts 
entirely before any formal action. A large number of drafts was submitted in 
the last days as well, i.e., my reading list is not empty. And at least I do 
have a day job, too.

2/ The TCPM chairs live in different time zones and usually sync before 
decisions. The RTT may be 12h+X.

3/ I am not sure whether we have to seriously discuss *whether* to adopt a 
widely implemented specification. But there could be some questions on the 
*how*. For instance, would ICCRG have to be in the loop? 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)? And are there any TCP RFCs that 
assume that only a single standard congestion control exist and that would 
perhaps have to be updated? Maybe the TCPM chairs have to do some homework 
that cannot be completed easily within 2 days?

Michael

PS: As individual contributor, I obviously support adoption.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Feb 2021 21:46:49 +0200

Hi,

> the last days as well, i.e., my reading list is not empty. And at least I do

understood. I did make the same request when -01 was posted already, hence I was wondering if it had fallen through the cracks.

> *how*. For instance, would ICCRG have to be in the loop?

They could, but I don't know if they have to. IIRC we run new CC schemes by them for review, but this isn't really one of those.

> How about use beyond
> 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.

> And are there any TCP RFCs that
> 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.

Thanks,
Lars

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 24 Feb 2021 20:27:13 +0000

> 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...

> 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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 24 Feb 2021 23:20:34 +0200

Hi,

> 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 some…

we certainly can, there are no downsides IMO. I'd be surprised if we saw significant feedback that we'd otherwise not see though.

> 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 a…

I think the text in 793bis is fine as-is. If we're still making changes to that, we could add some text about CUBIC being a specific suitable alternative, but I see no strong reason to argue for that.

Thanks,
Lars

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 25 Feb 2021 05:54:11 -0800 (PST)

Hello Lars, WG members,
	One comment inline below marked [RWG]

> 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,…

 [RWG] I think the difference here that may warrant at least some updates to some RFC's is that CUBIC is moving to a PS.  So any existing STD or PS that is affected by the fact there is now a new CC at PS level should be updated to reflect that availability.

Regards,
Rod

-- 
Rod Grimes                                                 [email-masked]

---

From: Martin Duke <[email-masked]>
Date: Thu, 25 Feb 2021 11:25:20 -0800

IMO a courtesy notice to QUIC, TSVWG, and ICCRG should be sufficient to
alert all potentially interested parties to come to TCPM if they want to
mix it up on this subject.

Obviously we should also periodically update these groups as the document
evolves.

On Thu, Feb 25, 2021 at 5:54 AM Rodney W. Grimes <[email-masked]>
wrote:

> > understood. I did make the same request when -01 was posted already,
> hence I was wondering if it had fallen through the cracks.
> >
> > They could, but I don't know if they have to. IIRC we run new CC schemes
> by them for review, but this isn't really one of those.
> >
> > > How about use beyond
> > 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.
> >
> > 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.
>
>  [RWG] I think the difference here that may warrant at least some updates
> to some RFC's is that CUBIC is moving to a PS.  So any existing STD or PS
> that is affected by the fact there is now a new CC at PS level should be
> updated to reflect that availability.
>
> Regards,
> Rod
>
> > Thanks,
> > Lars
> >
>
>