Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 6 Feb 2022 03:01:23 -0800

Hi,
I just have one more comment on the draft.
In RFC5681, it mentions in Section 3:
''

   Implementation Note: An easy mistake to make is to simply use cwnd,
   rather than FlightSize, which in some implementations may
   incidentally increase well beyond rwnd.

"

while this draft mentions in Section 4.6:
"

   To avoid suboptimal performance with such applications,

   the mechanisms described in [RFC7661
<https://datatracker.ietf.org/doc/html/rfc7661>] can be used to
mitigate this
   issue as it would allow using a value between _cwnd_ and
   _flight_size_ to calculate the new _ssthresh_ in Figure 5.

"

So, it seems one PS doc mentions not to use cwnd, while another PS doc
mentions using cwnd is fine (with RFC7661).

I am not sure which can cause this situation yet, but in any case, does
this mean there is no concern on
"some implementations may incidentally increase well beyond rwnd" in cubic?
Is this because this is an old implementation bug or are there other
reasons?
I am wondering if we might want some clarification on this point.

Also, I am wondering if we might want to use "MAY be used" here instead of
"can be used"

Thanks,
--
Yoshi

On Mon, Jan 31, 2022 at 11:43 PM Yoshifumi Nishida <[email-masked]>
wrote:

> Hello,
>
> After some discussions among chairs, we decided to run the 2nd WGLC on
> draft-ietf-tcpm-rfc8312bis in consideration of the importance of the draft.
> We'll be grateful if you could send your feedback to the ML. The WGLC runs
> until *Feb 11*.
>
> If interested, you can check in-depth past discussions in the following
> URL.
> https://github.com/NTAP/rfc8312bis/
>
> Thank you so much!
> --
> tcpm co-chairs
>
>
> On Wed, Jan 26, 2022 at 2:50 AM Lars Eggert <[email-masked]> wrote:
>
>> Hi,
>>
>> this -06 version rolls in all the changes requested during (and after)
>> WGLC ended.
>>
>> I'll leave it up to the chairs to decide if another WGLC is warranted or
>> the document can progress as-is.
>>
>> Thanks,
>> Lars
>>
>>
>> > On 2022-1-26, at 11:12, [email-masked] wrote:
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the TCP Maintenance and Minor Extensions
>> WG of the IETF.
>> >
>> >        Title           : CUBIC for Fast and Long-Distance Networks
>> >        Authors         : Lisong Xu
>> >                          Sangtae Ha
>> >                          Injong Rhee
>> >                          Vidhi Goel
>> >                          Lars Eggert
>> >       Filename        : draft-ietf-tcpm-rfc8312bis-06.txt
>> >       Pages           : 35
>> >       Date            : 2022-01-26
>> >
>> > Abstract:
>> >   CUBIC is a standard TCP congestion control algorithm that uses a
>> >   cubic function instead of a linear congestion window increase
>> >   function to improve scalability and stability over fast and long-
>> >   distance networks.  CUBIC has been adopted as the default TCP
>> >   congestion control algorithm by the 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 RFC 8312.  This also requires updating RFC 5681, to allow
>> >   for CUBIC's occasionally more aggressive sending behavior.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/
>> >
>> > There is also an HTML version available at:
>> > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06
>> >
>> >
>> > Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>> >
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/tcpm
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 6 Feb 2022 03:02:32 -0800

Hi Vidhi,

On Thu, Jan 27, 2022 at 4:35 PM Vidhi Goel <[email-masked]> wrote:

> Also, I am wondering if https://github.com/NTAP/rfc8312bis/issues/135 has
> been solved completely.
> Have we decided to leave this part as it is? We don't need any texts here
> or are there any future plans?
>
> We have discussed internally and decided to leave it as is. The
> justification is - there is already large scale deployment of CUBIC in
> the field with Beta_cubic = 0.7. We had added the below line to the draft
> as a caution. To change B_cubic for so many deployments, it would require a
> lot of experimental data and perhaps even some deployment experience. Such
> a change would be categorized as a research initiative before it makes it
> to an IETF draft.
>
> *A side effect of setting βcubic to a value bigger than 0.5 is slower
> convergence. We believe that while a more adaptive setting of βcubic could
> result in faster convergence, it will make the analysis of CUBIC much
> harder.*
>

OK. I've thought about this and I am fine with this as long as we recommend
using hystart++ or other burst mitigations during slow start (which is
already done)
--
Yoshi

---

From: Vidhi Goel <[email-masked]>
Date: Mon, 07 Feb 2022 15:32:39 -0800

Thanks Yoshi for reviewing the draft.

> So, it seems one PS doc mentions not to use cwnd, while another PS doc mentions using cwnd is fine (with RFC7661).
RFC5681 is conservative in its approach to use FlightSize and will result in very low throughput in scenarios when the congestion event occurs at the tail of send window (when flight size could be very small)

> I am not sure which can cause this situation yet, but in any case, does this mean there is no concern on 
> Is this because this is an old implementation bug or are there other reasons?
If an implementation uses RFC7661, there is no concern about increasing cwnd beyond rwnd as RFC7661 tracks bytes acknowledged in a RTT which means that `rwnd` check has already been performed.
Usually cwnd doesn’t grow beyond rwnd  (ACK-clocking increases cwnd which means the sender already checked 	`rwnd` before sending out the data).

But there could be implementations that may want to keep `rwnd` even smaller than initial `cwnd`. In those cases, RFC7661 would make the cwnd invalidated when the number of acknowledged bytes is much lower than the current cwnd.

Do you have any suggestions on how to make it more clear?

> Also, I am wondering if we might want to use "MAY be used" here instead of "can be used"  
Yeah, we can make this change.

I have opened an issue in GitHub https://github.com/NTAP/rfc8312bis/issues/143 <https://github.com/NTAP/rfc8312bis/issues/143>. We can continue the discussion there.

Thanks,
Vidhi

> On Feb 6, 2022, at 3:01 AM, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi,
>    the mechanisms described in [RFC7661 <https://datatracker.ietf.org/doc/html/rfc7661>] can be used to mitigate this
> So, it seems one PS doc mentions not to use cwnd, while another PS doc mentions using cwnd is fine (with RFC7661).
> 
> I am not sure which can cause this situation yet, but in any case, does this mean there is no concern on 
> Is this because this is an old implementation bug or are there other reasons?
> Also, I am wondering if we might want to use "MAY be used" here instead of "can be used"  
> 
> Thanks,
> --
> Yoshi
> 
> On Mon, Jan 31, 2022 at 11:43 PM Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>> wrote:
> Hello,
> 
> After some discussions among chairs, we decided to run the 2nd WGLC on draft-ietf-tcpm-rfc8312bis in consideration of the importance of the draft. 
> We'll be grateful if you could send your feedback to the ML. The WGLC runs until *Feb 11*.
> 
> If interested, you can check in-depth past discussions in the following URL.
> https://github.com/NTAP/rfc8312bis/ <https://github.com/NTAP/rfc8312bis/>
> 
> Thank you so much!
> --
> tcpm co-chairs
> 
> 
> On Wed, Jan 26, 2022 at 2:50 AM Lars Eggert <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> this -06 version rolls in all the changes requested during (and after) WGLC ended.
> 
> I'll leave it up to the chairs to decide if another WGLC is warranted or the document can progress as-is.
> 
> Thanks,
> Lars
> 
> 
> > On 2022-1-26, at 11:12, [email-masked] <mailto:[email-masked]> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/>
> > 
> > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html <https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html>
> > 
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06>
> > 
> > 
> > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> > 
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 9 Feb 2022 02:01:12 -0800

Hi Vidhi,

Thanks for the comments.

On Mon, Feb 7, 2022 at 3:32 PM Vidhi Goel <[email-masked]> wrote:

> RFC5681 is conservative in its approach to use FlightSize and will result
> in very low throughput in scenarios when the congestion event occurs at the
> tail of send window (when flight size could be very small)
>

Yes. I agree.

> If an implementation uses RFC7661, there is no concern about increasing
> cwnd beyond rwnd as RFC7661 tracks bytes acknowledged in a RTT which means
> that `rwnd` check has already been performed.
> Usually cwnd doesn’t grow beyond rwnd  (ACK-clocking increases cwnd which
> means the sender already checked `rwnd` before sending out the data).
>
> But there could be implementations that may want to keep `rwnd` even
> smaller than initial `cwnd`. In those cases, RFC7661 would make the cwnd
> invalidated when the number of acknowledged bytes is much lower than the
> current cwnd.
>

I think it will be fine as long as the draft clarifies we can safely
override what's written in RFC5681 when we have some mechanisms such as
RFC7661.

> Yeah, we can make this change.

Thanks!
-- 
Yoshi

---

From: Markku Kojo <[email-masked]>
Date: Sat, 12 Feb 2022 07:34:24 +0200 (EET)

Hi Yoshi, all,

It seems to me that many issues that I raised have been solved, thanks. 
However, there are still a number of important issues that have not been 
addressed adequately. At least the following:

#135 on W_max. Yoshi's observation was correct that this is not resolved: 
the co-authors and original developpers of CUBIC (@lisongxu and 
@sangtaeha) agreed in their last message that Wmax needs different 
treatment for slow start and congestion avoidance and plan comprehensive 
(new) evaluation of it. This is obviously an open issue but the issue 
was closed?

#85 (& #86 with basically same issue and these two were combined) This 
(#85) is about ECN but the major issue is on using the same MD 
factor in slow start and in congestion avoidance when using 
loss-based CC. This (#85) remained closed even though I provided a 
thorough explanation why it is wrong and against the original theory and 
design by Van Jacobson, against the congestion control principles (RFC 
2914) and two co-authors agreed on this in their same last message to 
#135 when they agreed on Wmax needing rework. This is an important issue 
that the wg should consider very carefully because it is not only 
updating RFC 5681 but also in conflict with RFC 2914. How can 
tcpm (and IETF) suggest and allow one CC algo to not follow congestion 
control principles as set in RFC 2914 while requiring all other CCs to 
follow RFC 2914 guidelines?
The current draft does not provide any justification for using the same 
MD factor in slow start as in congestion avoidance. Nor am I 
awere of any experimental data that would support this change. 
The fact thet CUBIC has been long deployed does not alone provide any 
supporting evidence because CUBIC is likely to give good performance as 
it is overagressive and thereby unfair to competing traffic and users 
tend to be happy when measuring the performance of the sending CUBIC 
only, not the competing traffic that is badly impacted. HyStart++ is 
suggested as mitigation to the problem but it cannot; HyStart++ is only 
applicable during initial slow start, not during slow start after RTO! 
That is, the "SHOULD use HYStart++" text in Sec 4.10 is impossible 
to implement as I have pointed out in my comments earlier. Using a proper 
MD factor in slow start is even more important if loss is detectected 
during a RTO recovery because the sender is likely to face heavy 
congestion in such a case and it is very bad if the sender continues 
sending with overaggressive rate, stealing the capacity from and causing 
harm to coexisting flows. In addition, as I have explained, HyStart++ 
does not remove the problem even for the initial slow start as it is not 
shown to work always. Instead, the results with the HyStart++ draft show 
that it reduces 50% of rexmits and only 36% RTOs, meaning that there is 
likely to be a notable percentage of cases when a sender is still 
in slow start when first loss is detected (i.e., HyStart++ had no effect) 
and a significant number of cases where a CUBIC sender is 
overaggressive continuing with a 1-40% larger cwnd than what is the 
available capacity. Note also that any delay-based heuristics like 
HyStart++ are known to work poorly in various wireless environmens where 
link delay tends to vary a lot. We may come up with some other MD factor 
that 0.5 when in slow start and HyStart++ is in use, but that is 
experimental, if not research, and definitely not ready for stds track.

#114, #132, and #143 w.r.t flightsize vs. cwnd. The current text
      does not quite correcly reflect what stacks that use cwnd do.
      I'll comment in #143 separately.

#96 & #98: The text added does not address the problems raised which are 
also evidenced in the paper pointed by Bob in #96. Even though CUBIC has 
been modified a bit after the paper was published, it does not 
automatically mean that the problem has been shown resolved: experimental 
evidence is required but not provided. The fact that CUBIC does not 
change MD factor for fast convergence is the root of the problem 
evidenced in the paper and remains so in the algo specified in this 
draft. This is also a significant problem when competing with Reno CC 
because CUBIC behaves much more aggressive than Reno CC when there is 
sudden congestion and all competing flows must converge fast down to a 
small fraction of the current cwnd to be fair to each other. This again 
cannot be evidenced not to be a problem by long deployment experience 
unless experimental data that measures the impact on competing traffic is 
presented to back the claims. Adjusting just Wmax for fast convergence is 
not enough and is even likely to be ineffective because there tend to be 
several losses when sudden congestion is hit, and particularly if NewReno 
is in use the sender stays several RTTs in Fast Recovery being 
overaggressive and then possibly continues at the same rate in CA which 
is unlikely to reach evan close to Wmax before a new loss hits 
the sender again. That is, lower Wmax and lower additive increase factor 
do not compensate the use of larger MD factor when sudden congestion is 
encountered.

#93 & #94 & (#89) Sec 5.3 still does not address any difficult 
environments, in particular buffer-bloated paths (nor does Sec 5.4).
We need evidence (results) that show CUBIC is fair towards other CCs 
(Reno) also in such environments. Note that CUBIC's decision to leave 
Reno-friendly region is based on the size of cwnd which tends to be 
incorrect with buffer-bloated bottlenecks because with huge buffers the 
cwnd can be many times larger than what is actually needed to fully 
utilize the available network bit-rate. Therefore, Reno CC has no problem 
in fully utilizing such bottleneck links and CUBIC must stay in 
Reno-friendly region longer but it leaves it too early because the same C 
is used as with non-bloated environments. We lack experiments showing 
CUBIC follows the congestion control principles and is fair to current 
standard TCP CC; to my understanding no experiments with buffer-bloated
bottlenecks are cited to back up the claims even though buffer bloat is 
very well known to be a common (difficult) environment in today's 
Internet.

#90 The current text on applying undo (a response to detected false 
fastrexmit) does not provide correct result if someone implements it.
I have explained the problems there in github but seem to have not 
replied to latest comments by Neal. I'll reply and try to explain more.
Again one major problem here is that the draft suggest a new response 
algo for false fast rexmits but does not provide any experimental data to 
support it. Long deployment experience has been suggested as 
justification but again without any carefully evaluated experimental 
data and evidence there is no meat. The issue is important to solve but is 
not specific to CUBIC. Instead, it is general problem for all TCP CC 
variants. IMHO, this is not ready for standards track but deserves a draft 
of its own so that it can be carefully evaluated and discussed ion the 
list. AFAIK there has been no discussion on this on the tcpm list, so 
those probably interested and having experience are likely to be unaware 
that this is part of CUBIC draft.

#88 The problem with correctness of the AIMD model and setting alpha for 
CUBIC requires further consideration. Bob provided an analysis that 
leaves things still open. It seems that I never had time to review and 
comment the analysis and clarify why the model does not work. I'll do that 
separately as it is important to ensure CUBIC behaves fairly as intended 
for the Reno-friendly region.

Best regards,

/Markku

On Mon, 31 Jan 2022, Yoshifumi Nishida wrote:

> Hello,
> 
> After some discussions among chairs, we decided to run the 2nd WGLC on draft-ietf-tcpm-rfc8312bis in
> consideration of the importance of the draft.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 15 Feb 2022 23:42:57 -0800

Hi Markku,

Thanks for the comments. I think these are very valid points.
However, I would like to check several things as a co-chair and a doc
shepherd before we discuss the points you've raised.

In my understanding (please correct me if I'm wrong), when this draft was
adopted as an WG item, I think the goal of the doc was some minor updates
from RFC8312 which include more clarifications, minor changes and bug
fixes.
However, if we try to address your concerns, I think we'll need to invent a
new version of CUBIC something like CUBIC++ or NewCUBIC in the end.
I won't deny the value of such doc, but, this seems not to be what we
agreed on beforehand.
if we proceed in this direction, I think we will need to check the WG
consensus whether this should be a new goal for the doc.

So, I would like to check if this is what you intend for the doc or you
think we can address your points while aligning with the original goal.
Also, if someone has opinions on this, please share.

Thanks,
--
Yoshi

On Fri, Feb 11, 2022 at 9:34 PM Markku Kojo <[email-masked]> wrote:

> draft-ietf-tcpm-rfc8312bis in
> >       I'll leave it up to the chairs to decide if another WGLC is
> warranted or the document can
> >       progress as-is.
> >
> >       Thanks,
> >       Lars
> >
> >

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 16 Feb 2022 15:39:58 -0800

+1 to what Yoshifumi said for a minor update.

On Tue, Feb 15, 2022 at 11:43 PM Yoshifumi Nishida <[email-masked]>
wrote:

> However, if we try to address your concerns, I think we'll need to invent
> a new version of CUBIC something like CUBIC++ or NewCUBIC in the end.

---

From: Markku Kojo <[email-masked]>
Date: Thu, 17 Feb 2022 16:41:29 +0200 (EET)

Hi Yoshi,

On Tue, 15 Feb 2022, Yoshifumi Nishida wrote:

> However, I would like to check several things as a co-chair and a doc shepherd before we
> discuss the points you've raised.
> 
> In my understanding (please correct me if I'm wrong), when this draft was adopted as an WG
> item, I think the goal of the doc was some minor updates from RFC8312 which include more
> clarifications, minor changes and bug fixes. 
> However, if we try to address your concerns, I think we'll need to invent a new version of
> CUBIC something like CUBIC++ or NewCUBIC in the end. 
> I won't deny the value of such doc, but, this seems not to be what we agreed on
> beforehand.  
> if we proceed in this direction, I think we will need to check the WG consensus whether
> this should be a new goal for the doc.
> 
> So, I would like to check if this is what you intend for the doc or you think we can
> address your points while aligning with the original goal.

I think it is important that we remember the status of RFC 8312 and the 
decades long process that has been followed in tsv area for new 
TCP congestion control algorithms that have been proposed and submitted 
to IETF. In order to ensure that new cc algos are safe and fair, the 
process that has been followed for all current stds track TCP cc algos 
has required that the cc algo is first accepted and published as 
experimental RFC and only once enough supportive experimental evidence 
has been gathered the doc has become a candidate to be forwaded to stds 
track. We have even agreed on a relatively strict evaluation process to 
follow when cc algos are brought to the IETF to be published as 
experimental:

https://www.ietf.org/about/groups/iesg/statements/experimental-congestion-control/

RFC 8312 was published as "Informational" and if I recall correctly the 
idea was "just to publish what's out there" for the benefit of the 
community. RFC 8312 was never really evaluated, particularly not in the 
way new cc algos are supposed to be as per the agreed process.

I do not recall what/how exactly was agreed when rfc8312bis was launched 
but I would be very interested to hear the justification why this doc 
does not need to follow the process mentioned above but we would like to 
propose IETF to publish a non-evaluated Informational doc to be published 
"with minor updates", i.e., without actual evaluation, as a stds track 
RFC? If the target really remains as PS then the bar should be even 
higher than what is described for experimental docs in the above process 
document, i.e, what we have followod for experimental to be moved to stds 
track.

The only justification that I have heard has beed "because CUBIC has long 
and wide deployment experience" and "the Internet has not smelted or that 
"we should have noticed if there were problems". We must, however, 
understand that in order to have noticeable bad impact CUBIC should cause 
some sort of congestion collapse. Congestion collapse, however, is not an 
issue with CUBIC nor with any other CC algo that applies an RTO mechanisms 
together with correctly implemented Karn's algo that retains the 
backed-off RTO until an Ack is received for a new (not rexmitted) data 
packet. The issue is fairness to competing traffic. This cannot be 
observed by deploying and measuring the performance and behaviour of CUBIC 
alone. CUBIC being more aggressive than current stds track TCP CC would 
just gives good performance results that one running CUBIC would be happy 
with. One must evaluate CUBIC's impact on the competing (Reno CC) traffic 
in range of environments which requires carefully designed active 
measurements with thoroughly-analyzed results (as required by the above 
process document, RFC 5033 and RFC 2914). What we seem to be missing is 
this evidence on CUBIC's impact and that is something the IETF must focus 
on, not just that whether CUBIC can achieve better performance than other 
existing CCs. The latter has been shown in many publications and is the 
majos focus in  many scientific papers proposing new algos.
I appreciate a lot that CUBIC has been implemented/developped and 
deployed for long and I wonder whether those deploying CUBIC have 
unpublished results the wg could review before taking the decicion?

I suggest everyone to read carefully RFC 2914 Sec 3.2 and particularly 
what it says about more aggressive (than RFC 5681) congestion control 
algorithms:

  Some of these may fail to implement
  the TCP congestion avoidance mechanisms correctly because of poor
  implementation [RFC2525].  Others may deliberately be implemented
  with congestion avoidance algorithms that are more aggressive in
  their use of bandwidth than other TCP implementations; this would
  allow a vendor to claim to have a "faster TCP".  The logical
  consequence of such implementations would be a spiral of increasingly
  aggressive TCP implementations, or increasingly aggressive transport
  protocols, leading back to the point where there is effectively no
  congestion avoidance and the Internet is chronically congested.

And:

  It is convenient to divide flows into three classes: (1) TCP-
  compatible flows, (2) unresponsive flows, i.e., flows that do not
  slow down when congestion occurs, and (3) flows that are responsive
  but are not TCP-compatible.  The last two classes contain more
  aggressive flows that pose significant threats to Internet
  performance,

As I have tried to point out there are several features with CUBIC where 
it is likely to be (or to me it seems it obviously is) more aggressive 
than what is reguired to be TCP-compatible. I'm not aware of evidince 
presented to tcpm (or IETF/IRTF) which shows opposite (and I happy to be 
educated what I have missed).

You may take my comments to be a part of the expert review phase 
performed by the IRTF/ICCRG for CUBIC. I'm not requesting to modify this 
doc to CUBIC++ (or something) but it seems to be that this would be 
necessary if this doc intends to become published as PS. For experimental, 
I think it would need some addtioinal updates and record the areas 
uncertainty and where more experimentation (clearly) is required.

Thanks,

/Markku

>       >       I'll leave it up to the chairs to decide if another WGLC is warranted
>       or the document can
>       >       progress as-is.
>       >
>       >       Thanks,
>       >       Lars
>       >
>       >
>       >       > On 2022-1-26, at 11:12, [email-masked] wrote:
>       >       >
>       >       >
>       >       > A New Internet-Draft is available from the on-line Internet-Drafts
>       directories.
>       >       > This draft is a work item of the TCP Maintenance and Minor
>       Extensions WG of the IETF.
>       >       >
>       >       >        Title           : CUBIC for Fast and Long-Distance Networks
>       >       >        Authors         : Lisong Xu
>       >       >                          Sangtae Ha
>       >       >                          Injong Rhee
>       >       >                          Vidhi Goel
>       >       >                          Lars Eggert
>       >       >       Filename        : draft-ietf-tcpm-rfc8312bis-06.txt
>       >       >       Pages           : 35
>       >       >       Date            : 2022-01-26
>       >       >
>       >       > Abstract:
>       >       >   CUBIC is a standard TCP congestion control algorithm that uses a
>       >       >   cubic function instead of a linear congestion window increase
>       >       >   function to improve scalability and stability over fast and long-
>       >       >   distance networks.  CUBIC has been adopted as the default TCP
>       >       >   congestion control algorithm by the 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 RFC 8312.  This also requires updating RFC 5681, to
>       allow
>       >       >   for CUBIC's occasionally more aggressive sending behavior.
>       >       >
>       >       >
>       >       > The IETF datatracker status page for this draft is:
>       >       > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/
>       >       >
>       >       > There is also an HTML version available at:
>       >       > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html
>       >       >
>       >       > A diff from the previous version is available at:
>       >       > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06
>       >       >
>       >       >
>       >       > Internet-Drafts are also available by rsync at
>       rsync.ietf.org::internet-drafts
>       >       >
>       >       >
>       >       > _______________________________________________
>       >       > tcpm mailing list
>       >       > [email-masked]
>       >       > https://www.ietf.org/mailman/listinfo/tcpm
>       >

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 17 Feb 2022 11:13:47 -0500

On Thu, Feb 17, 2022 at 9:42 AM Markku Kojo <kojo=
[email-masked]> wrote:

> agreed on
> think we can

Hi Markku,

Thanks for your careful argument above. Given your argument, in order to
continue to make constructive progress on rfc8312bis without blocking for
new research and experimentation, I would propose that we change rfc8312bis
so that it remains "Informational" (like RFC8312) rather than the
"Standards Track" status currently listed at:

  https://ntap.github.io/rfc8312bis/draft-ietf-tcpm-rfc8312bis.html

As far as I can tell, that would allow all of the valuable contributions in
rfc8312bis to carry forward and be published, while still respecting all of
the considerations you enumerated above, which center around concerns with
calling CUBIC "standards track".

How does that sound?

best,
neal

---

From: Vidhi Goel <[email-masked]>
Date: Thu, 17 Feb 2022 18:13:54 -0800

I have a general question for the WG, are the "current practices" defined in https://datatracker.ietf.org/doc/html/rfc2914 <https://datatracker.ietf.org/doc/html/rfc2914> still current? We are 22 years ahead of the published date of this draft and there have been magnitude of advancements in congestion control algorithms at the hosts and what is the right way to measure conformance for a congestion control. A very interesting paper about how to quantify a new congestion control, which most might have read, "Beyond Jain's Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms"

I skimmed through RFC 2914 and it references obsoleted drafts for what it calls conformant TCP. Like below:

For TCP, this
   means congestion control algorithms conformant with the current TCP
   specification [RFC793, RFC1122 <https://datatracker.ietf.org/doc/html/rfc1122>, RFC2581 <https://datatracker.ietf.org/doc/html/rfc2581>].

I don’t think we can continue to use old RFCs as a gold standard although we can use some the text as is if it still holds true.

>   congestion avoidance and the Internet is chronically congested.

For example, in this text quoted by Markku, I agree that we shouldn’t end up with algorithms that eventually lead to a chronically congested networks but at the same time, if a more aggressive approach provides better efficiency by ramping up a bit faster without leading to more congestion, then that shouldn’t be discouraged. Faster TCP doesn’t necessarily mean that will cause congestion, it could just mean, instead of waiting 100s of RTTs to get to full link utilization, it does so in much lesser number of RTTs.

In using Reno as a gold standard, we tend to forget that Reno is probably the cause of buffer bloat in the network. It basically requires network queues to be configured double the capacity in order to continue to have full link utilization after 50% reduction.
And again, this might not have been evident at the time Reno was developed. We have realized these problems with time and we should move away from continuing to use Reno as the only acceptable Proposed Stds track congestion control.

>   aggressive flows that pose significant threats to Internet

This second paragraph is also outdated. IIUC, TCP-compatible flows is equivalent to the RFC 2581 which is obsolete. I think we need to replace TCP-compatible with something else for two reasons:

1. TCP is not the only transport protocol out there. What about QUIC, SCTP?
2. Congestion control algorithms should be evaluated in the same way for different transport protocols. So, a better word could be, Conformant congestion control, one which once accepted as Stds Track should just work for any transport protocol.

Perhaps, we need to show more experimental / deployment data for Cubic to become Stds Track but we shouldn’t rely on RFC2914 from the year 2000 to decide the acceptance criteria. If we continue to do so, then even 100 years from now, RFC 5681 will be the only TCP-conformant / TCP-compatible congestion control as defined by RFC 2914 and the one and only Stds Track congestion control to ever exist. (Please let me know if I missed any other Stds Track congestion control)

Thanks,
Vidhi

> On Feb 17, 2022, at 8:13 AM, Neal Cardwell <ncardwell=[email-masked]> wrote:
> 
> 
> 
> On Thu, Feb 17, 2022 at 9:42 AM Markku Kojo <kojo=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Yoshi,
> 
> https://www.ietf.org/about/groups/iesg/statements/experimental-congestion-control/ <https://www.ietf.org/about/groups/iesg/statements/experimental-congestion-control/>
> 
> Thanks for your careful argument above. Given your argument, in order to continue to make constructive progress on rfc8312bis without blocking for new research and experimentation, I would propose that we change rfc8312bis so that it remains "Informational" (like RFC8312) rather than the "Standards Track" status currently listed at:
> 
>   https://ntap.github.io/rfc8312bis/draft-ietf-tcpm-rfc8312bis.html <https://ntap.github.io/rfc8312bis/draft-ietf-tcpm-rfc8312bis.html>
> 
> As far as I can tell, that would allow all of the valuable contributions in rfc8312bis to carry forward and be published, while still respecting all of the considerations you enumerated above, which center around concerns with calling CUBIC "standards track".
> 
> How does that sound?
> 
> best,
> neal
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 18 Feb 2022 00:39:44 -0800

Hi Markku,

Thanks for the comments. Yes, these are valid and important concerns.
However, I have mixed feelings about them.
I don't want to open a can of worms, but here's are some of my personally
thoughts...

One thing is that "long and wide deployment experience" might not be a very
strong claim, but then, I am wondering what would be the strong one.
One may bring some solid experiment results, but the others might argue it
uses too convenient configurations, or the scale is too small or too short.

The other thing is that if we set a high bar for a PS doc related to CC, we
should apply the same bar to all related docs.
For example, I am personally wondering how much we have analyzed and
performed experiments when we published RFC9002. (BTW, my intention is NOT
to accuse a specific doc, there should be some more examples.)
I am not sure how we can maintain this kind of fairness between the docs at
the moment.

Thanks,
--
Yoshi

On Thu, Feb 17, 2022 at 6:41 AM Markku Kojo <[email-masked]> wrote:

> >       >       > This draft is a work item of the TCP Maintenance and
> Minor
> >       >       >   congestion control algorithm by the Linux, Windows,
> and Apple
> >       stacks.
> >       >       >
> >       >       >   obsoleting RFC 8312.  This also requires updating RFC
> 5681, to
> >       allow

---

From: Markku Kojo <[email-masked]>
Date: Fri, 18 Feb 2022 12:23:42 +0200 (EET)

Hi Yoshi,

On Fri, 18 Feb 2022, Yoshifumi Nishida wrote:

> Hi Markku,
> 
> Thanks for the comments. Yes, these are valid and important concerns. However, I have
> mixed feelings about them.
> I don't want to open a can of worms, but here's are some of my personally thoughts...
> 
> One thing is that "long and wide deployment experience" might not be a very strong claim,
> but then, I am wondering what would be the strong one.
> One may bring some solid experiment results, but the others might argue it uses too
> convenient configurations, or the scale is too small or too short.

Well, that has always been and IMO still is for the wg to decide when the 
evidence through experiments is good enough to proceed with publishing the 
doc. E.g., when RFC 5562 was considered for publication by the wg, the wg 
requested for more experiments before making the decision and Sally 
provided what was requested. And it was just about adding ECN capability 
to SYNACK but here we are discussing much more significant changes.

And more importantly, here we are mainly discussing whether there is any 
experimental evidence at all; for example, changing MD (from 0.5 to 0.7 or 
to whatever) must be considered separately when in slow start and when in 
congestion avoidance as I have pointed out. This requires tests that 
specifically target at studying the slow start overshoot phase and the 
following recovery phase. AFAIK, there are no such experimental results, 
no analysis nor evaluation presented to support the change when 
the sender is in slow start. So, we are not discussing the level of 
evidence but whether it exists at all, which is very different.

> The other thing is that if we set a high bar for a PS doc related to CC, we should apply
> the same bar to all related docs.For example, I am personally wondering how much we have
> analyzed and performed experiments when we published RFC9002. (BTW, my intention is NOT to
> accuse a specific doc, there should be some more examples.) 

Yes, IMO the bar should be the same. RFC 9002 was first targetted as 
experimental but was later changed to PS. I did not have time to follow 
the progress much at all but in my opinion it would probably have been 
better to publish it also as experimental first. On the other hand, it 
intends to implement NewReno as close as possible, and therefore not to 
change the congestion control principles that we have. I cannot tell how 
much experimental effort was put to verify the behaviour of those features 
that are new in QUIC and/or differ from stds track TCP but hopefully 
good enough. (Though there seems to be one issue related to resetting the 
exponential backoff of PTO, which seems to require a more accurate 
specification to ensure unambiguous interpretation and correct outcome, 
but that's an off topic here).

> I am not sure how we can maintain this kind of fairness between the docs at the moment.

I think it is the responsibility for the entire tsv area to do it, and 
eventually the TSV ADs and IESG. The process to follow is clear and 
robust, and when followed it has shown to be effectual in producing good 
quality documents. AFAIK, we have not decided to change it, maybe just 
many of us are unaware of it or have forgotten its existence?
Traditionally tsv area has been very careful in considering new CC 
proposals because congestion control is so essential for the stability 
and fairness of the Internet and I hope we are not sliping too much from 
there. AFAIK, that's one reason why the process was documented.

Thanks,

/Markku

>       adopted as an WG
>       new version of
>       >       > Hello,
>       >       > After some discussions among chairs, we decided to run the 2nd WGLC
>       on
>       >       > consideration of the importance of the draft. 
>       >       > We'll be grateful if you could send your feedback to the ML. The
>       WGLC runs
>       >       until *Feb 11*.
>       >       >
>       >       > If interested, you can check in-depth past discussions in the
>       following URL.
>       >       > https://github.com/NTAP/rfc8312bis/
>       >       >
>       >       > Thank you so much!
>       >       > --
>       >       > tcpm co-chairs
>       >       >
>       >       >
>       >       > On Wed, Jan 26, 2022 at 2:50 AM Lars Eggert <[email-masked]> wrote:
>       >       >       Hi,
>       >       >
>       >       >       this -06 version rolls in all the changes requested during
>       (and after)
>       >       WGLC ended.
>       >       >
>       >       >       I'll leave it up to the chairs to decide if another WGLC is
>       warranted
>       >       or the document can
>       >       >       progress as-is.
>       >       >
>       >       >       Thanks,
>       >       >       Lars
>       >       >
>       >       >
>       >       >       > On 2022-1-26, at 11:12, [email-masked] wrote:
>       >       >       >
>       >       >       >
>       >       >       > A New Internet-Draft is available from the on-line
>       Internet-Drafts
>       >       directories.
>       >       >       > This draft is a work item of the TCP Maintenance and Minor
>       >       >       >
>       >       >       >        Title           : CUBIC for Fast and Long-Distance
>       Networks
>       >       >       >        Authors         : Lisong Xu
>       >       >       >                          Sangtae Ha
>       >       >       >                          Injong Rhee
>       >       >       >                          Vidhi Goel
>       >       >       >                          Lars Eggert
>       >       >       >       Filename        : draft-ietf-tcpm-rfc8312bis-06.txt
>       >       >       >       Pages           : 35
>       >       >       >       Date            : 2022-01-26
>       >       >       >
>       >       >       > Abstract:
>       >       >       >   CUBIC is a standard TCP congestion control algorithm that
>       uses a
>       >       >       >   cubic function instead of a linear congestion window
>       increase
>       >       >       >   function to improve scalability and stability over fast
>       and long-
>       >       >       >   distance networks.  CUBIC has been adopted as the default
>       TCP
>       >       >       >   congestion control algorithm by the 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 RFC 8312.  This also requires updating RFC
>       5681, to
>       >       allow
>       >       >       >   for CUBIC's occasionally more aggressive sending behavior.
>       >       >       >
>       >       >       >
>       >       >       > The IETF datatracker status page for this draft is:
>       >       >       > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/
>       >       >       >
>       >       >       > There is also an HTML version available at:
>       >       >       >
>       >       >       >
>       >       >       > A diff from the previous version is available at:
>       >       >       >
>       >       >       >
>       >       >       >
>       >       >       > Internet-Drafts are also available by rsync at
>       >       >       >
>       >       >       >
>       >       >       > _______________________________________________
>       >       >       > tcpm mailing list
>       >       >       > [email-masked]
>       >       >       > https://www.ietf.org/mailman/listinfo/tcpm
>       >       >

---

From: Markku Kojo <[email-masked]>
Date: Fri, 18 Feb 2022 12:26:34 +0200 (EET)

Hi Neal,

On Thu, 17 Feb 2022, Neal Cardwell wrote:

> 
> 
> On Thu, Feb 17, 2022 at 9:42 AM Markku Kojo <kojo=[email-masked]> wrote:
>       Hi Yoshi,
>
> Thanks for your careful argument above. Given your argument, in order to continue to make
> constructive progress on rfc8312bis without blocking for new research and experimentation,
> I would propose that we change rfc8312bis so that it remains "Informational" (like
> RFC8312) rather than the "Standards Track" status currently listed at:
> 
> As far as I can tell, that would allow all of the valuable contributions in rfc8312bis to
> carry forward and be published, while still respecting all of the considerations you
> enumerated above, which center around concerns with calling CUBIC "standards track".
> 
> How does that sound?

Sure, that could be one possible path forward. In my opinion, publishing 
it as experimental would be more logical and would also provide an 
inherent path forward to PS once enough evidence has been gathered and wg 
considers it is mature enough to proceed.  I don't have a strong opinion 
on this. Either way, IMO, it would be important to clearly point out and 
discuss the areas that require more evaluation so that it encourages 
interested parties to focus their experimentation to those important 
areas.

Thanks,

/Markku

---

From: Vidhi Goel <[email-masked]>
Date: Fri, 18 Feb 2022 02:39:14 -0800

> Yes, IMO the bar should be the same. RFC 9002 was first targetted as experimental but was later changed to PS. I did not have time to follow the progress much at all but in my opinion it would probably have been better to publish it also as experimental first. On the other hand, it intends to implement NewReno as close as possible, and therefore not to change the congestion control principles that we have. I cannot tell how much experimental effort was put to verify the behaviour of those features that are new in QUIC and/or differ from stds track TCP but hopefully good enough. (Though there seems to be one issue related to resetting the exponential backoff of PTO, which seems to require a more accurate specification to ensure unambiguous interpretation and correct outcome, but that's an off topic here).

RFC 9002 deviates from Reno as it uses `cwnd` during multiplicative decrease on a congestion event - https://www.rfc-editor.org/rfc/rfc9002.html#name-on-new-congestion-event <https://www.rfc-editor.org/rfc/rfc9002.html#name-on-new-congestion-event>. This is definitely a strong deviation from RFC 5681 which clearly mentions not to use cwnd.
Its good to know that you are hopeful about the experimental effort put in RFC 9002 without the evidence being explicitly presented at IETF.

Thanks,
Vidhi

> On Feb 18, 2022, at 2:23 AM, Markku Kojo <kojo=[email-masked]> wrote:
> 
> Hi Yoshi,
> 
> Well, that has always been and IMO still is for the wg to decide when the evidence through experiments is good enough to proceed with publishing the doc. E.g., when RFC 5562 was considered for publication by the wg, the wg requested for more experiments before making the decision and Sally provided what was requested. And it was just about adding ECN capability to SYNACK but here we are discussing much more significant changes.
> 
> And more importantly, here we are mainly discussing whether there is any experimental evidence at all; for example, changing MD (from 0.5 to 0.7 or to whatever) must be considered separately when in slow start and when in congestion avoidance as I have pointed out. This requires tests that specifically target at studying the slow start overshoot phase and the following recovery phase. AFAIK, there are no such experimental results, no analysis nor evaluation presented to support the change when the sender is in slow start. So, we are not discussing the level of evidence but whether it exists at all, which is very different.
> 
> Yes, IMO the bar should be the same. RFC 9002 was first targetted as experimental but was later changed to PS. I did not have time to follow the progress much at all but in my opinion it would probably have been better to publish it also as experimental first. On the other hand, it intends to implement NewReno as close as possible, and therefore not to change the congestion control principles that we have. I cannot tell how much experimental effort was put to verify the behaviour of those features that are new in QUIC and/or differ from stds track TCP but hopefully good enough. (Though there seems to be one issue related to resetting the exponential backoff of PTO, which seems to require a more accurate specification to ensure unambiguous interpretation and correct outcome, but that's an off topic here).
> 
> I think it is the responsibility for the entire tsv area to do it, and eventually the TSV ADs and IESG. The process to follow is clear and robust, and when followed it has shown to be effectual in producing good quality documents. AFAIK, we have not decided to change it, maybe just many of us are unaware of it or have forgotten its existence?
> Traditionally tsv area has been very careful in considering new CC proposals because congestion control is so essential for the stability and fairness of the Internet and I hope we are not sliping too much from there. AFAIK, that's one reason why the process was documented.
> 
> Thanks,
> 
> /Markku
> 
>> Thanks,
>> --
>> Yoshi 
>>      >       >       >   congestion control algorithm by the Linux, Windows, and
>>      Apple
>>      >       stacks.
>>      >       >       >

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 18 Feb 2022 09:46:26 -0500

> On Thu, 17 Feb 2022, Neal Cardwell wrote:
...

> continue to make

Great. Slating rfc8312bis as "Experimental" sounds like a great solution to
me.

And I agree it would be great to "clearly point out and discuss the areas
that require more evaluation", for the reason you note. To speed forward
progress, would you like to propose a github pull request to add an
appendix that enumerates those areas?

thanks,
neal

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 21 Feb 2022 02:43:04 -0800

Hi Markku,

I've thought about this over the weekend. Changing the intended status of
the doc may look simple, but it might affect other docs as a precedent.
So, I would like to think about it a bit more.

I think it may be possible to do some experiments before we publish the doc
as a PS if it's not too complicated.
But, in this case, I think we'll need to delineate what we want to
evaluate.
One thing I am wondering is whether points are if there is a risk for
congestion collapse, or if this is too aggressive than NewReno or something
else.

If we think there's a risk for congestion collapse, we should be able to
describe which scenarios could lead such situations.
If we think CUBIC is too aggressive, I think we will need to define some
bars for it.
I think 9002 is more aggressive than TCP NewReno in some points.
So, if we reject CUBIC to be a PS due to its aggressiveness, I think there
should be a border for it.

Thanks,
--
Yoshi

On Fri, Feb 18, 2022 at 2:23 AM Markku Kojo <[email-masked]> wrote:

> >       > item, I think the goal of the doc was some minor updates from
> RFC8312 which
> >       include more
> >       > I won't deny the value of such doc, but, this seems not to be
> what we agreed
> >       on
> >       > beforehand.
> >       >       It seems to me that many issues that I raised have been
> solved,
> >       thanks.
> >       >       However, there are still a number of important issues that
> have not
> >       been
> >       >       #135 on W_max. Yoshi's observation was correct that this
> is not
> >       resolved:
> >       >       thorough explanation why it is wrong and against the
> original theory
> >       and
> >       >       #135 when they agreed on Wmax needing rework. This is an
> important
> >       issue
> >       >       The current draft does not provide any justification for
> using the
> >       same
> >       >       supporting evidence because CUBIC is likely to give good
> performance
> >       as
> >       >       suggested as mitigation to the problem but it cannot;
> HyStart++ is
> >       only
> >       >       to implement as I have pointed out in my comments earlier.
> Using a
> >       proper
> >       >       sending with overaggressive rate, stealing the capacity
> from and
> >       causing
> >       >       does not remove the problem even for the initial slow
> start as it is
> >       not
> >       >       shown to work always. Instead, the results with the
> HyStart++ draft
> >       show
> >       >       that it reduces 50% of rexmits and only 36% RTOs, meaning
> that there
> >       is
> >       >       in slow start when first loss is detected (i.e., HyStart++
> had no
> >       effect)
> >       >       HyStart++ are known to work poorly in various wireless
> environmens
> >       where
> >       >       link delay tends to vary a lot. We may come up with some
> other MD
> >       factor
> >       >       experimental, if not research, and definitely not ready
> for stds
> >       track.
> >       >
> >       >       #96 & #98: The text added does not address the problems
> raised which
> >       are
> >       >       also evidenced in the paper pointed by Bob in #96. Even
> though CUBIC
> >       has
> >       >       automatically mean that the problem has been shown
> resolved:
> >       experimental
> >       >       small fraction of the current cwnd to be fair to each
> other. This
> >       again
> >       >       unless experimental data that measures the impact on
> competing traffic
> >       is
> >       >       presented to back the claims. Adjusting just Wmax for fast
> convergence
> >       is
> >       >       not enough and is even likely to be ineffective because
> there tend to
> >       be
> >       >       several losses when sudden congestion is hit, and
> particularly if
> >       NewReno
> >       >       overaggressive and then possibly continues at the same
> rate in CA
> >       which
> >       >       the sender again. That is, lower Wmax and lower additive
> increase
> >       factor
> >       >       do not compensate the use of larger MD factor when sudden
> congestion
> >       is
> >       >       encountered.
> >       >
> >       >       incorrect with buffer-bloated bottlenecks because with
> huge buffers
> >       the
> >       >       utilize the available network bit-rate. Therefore, Reno CC
> has no
> >       problem
> >       >       Reno-friendly region longer but it leaves it too early
> because the
> >       same C
> >       >       bottlenecks are cited to back up the claims even though
> buffer bloat
> >       is
> >       >       replied to latest comments by Neal. I'll reply and try to
> explain
> >       more.
> >       >       algo for false fast rexmits but does not provide any
> experimental data
> >       to
> >       >       data and evidence there is no meat. The issue is important
> to solve
> >       but is
> >       >       variants. IMHO, this is not ready for standards track but
> deserves a
> >       draft
> >       >       those probably interested and having experience are likely
> to be
> >       unaware
> >       >       #88 The problem with correctness of the AIMD model and
> setting alpha
> >       for
> >       >       comment the analysis and clarify why the model does not
> work. I'll do
> >       that
> >       >       separately as it is important to ensure CUBIC behaves
> fairly as
> >       intended
> >       >       > After some discussions among chairs, we decided to run
> the 2nd WGLC
> >       on
> >       >       > We'll be grateful if you could send your feedback to the
> ML. The
> >       WGLC runs
> >       >       until *Feb 11*.
> >       >       >
> >       >       > If interested, you can check in-depth past discussions
> in the
> >       following URL.
> >       >       >       this -06 version rolls in all the changes
> requested during
> >       (and after)
> >       >       WGLC ended.
> >       >       >
> >       >       >       > A New Internet-Draft is available from the
> on-line
> >       Internet-Drafts
> >       >       directories.
> >       >       >       > This draft is a work item of the TCP Maintenance
> and Minor
> >       >       >       >        Title           : CUBIC for Fast and
> Long-Distance
> >       Networks
> >       >       >       >        Authors         : Lisong Xu
> >       >       >       >                          Sangtae Ha
> >       >       >       >                          Injong Rhee
> >       >       >       >                          Vidhi Goel
> >       >       >       >                          Lars Eggert
> >       >       >       >       Filename        :
> >       >       >       >   CUBIC is a standard TCP congestion control
> algorithm that
> >       uses a
> >       >       >       >   cubic function instead of a linear congestion
> window
> >       increase
> >       >       >       >   function to improve scalability and stability
> over fast
> >       and long-
> >       >       >       >   distance networks.  CUBIC has been adopted as
> the default
> >       TCP
> >       >       >       >   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,

---

From: Lars Eggert <[email-masked]>
Date: Mon, 21 Feb 2022 16:52:13 +0200

Hi,

first, as an editor (but not wearing other hats) I do object against reclassifying the document as Experimental or Informational, esp. this late in the process.

CUBIC is not a new CC proposal. It's been ubiquitously deployed on the Internet for many years. All major TCP stacks use it by default. Given that, I don't see how the IESG statement on "Experimental Specification of New Congestion Control Algorithms" applies here.

(As an aside, that statement was specifically written when CUBIC, Compound and Hamilton were all jostling for RFC publication. The community converged on CUBIC in the meantime.)

CUBIC *is* the default CC mechanism used on the Internet and in other IP networks. It should be published on the standards track.

Second, this is the second time that an individual raised a long list of issues after the WGLC has ended. We did try to work through all the issues that were raised after the first WGLC, but the individual often failed to participate in the discussion in a timely manner. I now see at least several of those same issues re-raised by the same individual. Before going down the same path a second time, I would actually ask the WG to confirm there is consensus that the raised issues are valid (and if they are valid, commit to contributing to a resolution in a timely manner.)

Thanks,
Lars

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Feb 2022 00:11:07 +0000

Yoshi, Markku,

Many of the technical points Markku raised were important omissions from 
the rfc8312bis draft. Whatever status we give the eventual RFC, they 
should be highlighted as areas that need further work, either known 
weaknesses or just areas where we don't have enough data to know whether 
they are weaknesses. I tried to help find useful references for 
experiments already done around those points, and I tried to help write 
such text.

However, I cannot agree with some of Markku's statements about process.

      #1: The rules can change

It's OK to quote RFCs, but it's also OK for us to reach consensus that 
certain aspects of old RFCs are outdated, as long as we give our 
reasons, and there is rough consensus around that. We are all consenting 
adults - we don't have to be limited by RFCs from the past if we 
collectively don't want to be.

I have not noticed a need for the above "rule #1" in this discussion 
yet, but I'm just putting it out there, so if anyone needs to invoke it 
later, they can't be accused of inventing a rule for their own convenience.

      #2: There is no TCP-compatibility requirement

Yes, CUBIC is not TCP-compatible. But that's a feature, not a bug. Words 
like 'TCP-compatible' or 'fair' sound nice, but do not be fooled into 
thinking that an RFC recommends or requires you to behave in a certain 
way just because it has used a nice-sounding word for it.

For an RFC to recommend or require something, it has to say SHOULD or 
MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks about 
what is necessary to be 'fair', it implies nothing about whether you 
should or must be TCP-compatible, or fair; unless it actually says you 
SHOULD or MUST be TCP-compatible, or fair. *No RFC says that.*

BCP 133 [RFC5033] and others have written careful words about straying 
from equal flow rates (quoted below). That gives a checklist for people 
like us who come along later. But it also respects our right to make a 
decision on whether/how to publish a CC RFC based on our own present-day 
knowledge and experience. To quote the relevant guideline in BCP 133 
[RFC5033]:

    (1) Impact on Standard TCP, SCTP [RFC2960  <https://www.rfc-editor.org/rfc/rfc2960>], and DCCP [RFC4340  <https://www.rfc-editor.org/rfc/rfc4340>].

        Proposed congestion control mechanisms should be evaluated when
        competing with standard IETF congestion control [RFC2581,
        RFC2960  <https://www.rfc-editor.org/rfc/rfc2960>,RFC4340  <https://www.rfc-editor.org/rfc/rfc4340>].  Alternate congestion controllers that have a
        significantly negative impact on traffic using standard
        congestion control may be suspect and this aspect should be part
        of the community's decision making with regards to the
        suitability of the alternate congestion control mechanism.

        We note that this bullet is not a requirement for strict TCP-
        friendliness as a prerequisite for an alternate congestion
        control mechanism to advance to Experimental.  As an example,
        HighSpeed TCP is a congestion control mechanism that is
        Experimental, but that is not TCP-friendly in all environments.
        We also note that this guideline does not constrain the fairness
        offered for non-best-effort traffic.

        As an example from an Experimental RFC, fairness with standard
        TCP is discussed in Sections4  <https://www.rfc-editor.org/rfc/rfc5033.html#section-4>  and6  <https://www.rfc-editor.org/rfc/rfc5033.html#section-6>  of [RFC3649  <https://www.rfc-editor.org/rfc/rfc3649>] (HighSpeed TCP)
        and*using spare capacity*  is discussed in Sections6  <https://www.rfc-editor.org/rfc/rfc5033.html#section-6>,11.1  <https://www.rfc-editor.org/rfc/rfc5033.html#section-11.1>, and12  <https://www.rfc-editor.org/rfc/rfc5033.html#section-12>
        of [RFC3649  <https://www.rfc-editor.org/rfc/rfc3649>].

The rfc8312bis draft has a section on 'using spare capacity' precisely 
because that's what was considered acceptable about CUBIC and the new 
generation of hi-BDP CCs developed at that time, as I've emphasized in 
the last para above.

      #3: A process for publishing EXP RFCs doesn't cover publishing
      non-EXP RFCs (by definition)

This IESG statement on "Experimental Specification of New Congestion 
Control Algorithms 
<https://www.ietf.org/about/groups/iesg/statements/experimental-congestion-control/>" 
says it defines the process for a CC to be published as an Experimental 
RFC. It does not say it is the process that /all/ CCs have to follow to 
enter the standards track.

Before invoking that process, one has to determine whether it is 
applicable to this case. The IESG statement contains a sentence about 
how to determine its applicability:

    The decision of whether a specific new congestion control schemes
    goes beyond the principles of [RFC2914] and hence will undergo the
    process described in this document lies with the transport area
    directors, who will use the expertise of the transport area
    directorate and other congestion control experts to aid their decision.

Since RFC2914, we've had RFC3246 explaining why Reno is unscalable, and 
RFC5033 (quoted above) giving guidelines for designers of new CCs. So we 
can debate whether the process that Markku quoted is relevant to this 
case, to help the AD to decide whether to follow the process or not.

      #4 EXP or STD? My view

Reno is worse than other CCs in some respects. Nearly everyone has 
abandoned it. So, if someone asked you why Reno is the IETF's only stds 
track CC, what would you say ...?

As I already said, we have to stop thinking that the stds track requires 
a CC algorithm to be perfect. A CC certainly mustn't have failure or 
collapse modes, but it's performance doesn't have to be perfect in all 
cases. For instance, CUBIC has known poor utilization over radio links. 
That didn't stop Reno from being on the stds track. For me, the IETF 
needs a new CC on the stds track, and CUBIC is the most natural candidate.

However, we must not set a precedent for any old CC to move to the stds 
track. So we must document it's weaknesses and failings, and explain why 
they are not serious (if that is the case).

New CCs need to interoperate with the most prevalent CC on the Internet 
(CUBIC). The IETF cannot even say that as long as it hasn't formally 
recognized CUBIC on the stds track. That is a failing of *us* in the 
tcpm WG. We can move CUBIC to stds track via the exp track if we have 
to, or we can go straight to stds track. The only difference is that the 
first option makes us look like jobsworths for longer.

jobsworth
/ˈdʒɒbzwəːθ/
/noun/
  derogatory•informal
an official who upholds petty rules even at the expense of humanity or 
common sense.
1970s: from "I can't do that, it's more than my job's worth."

Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 22 Feb 2022 10:03:38 +0000

Hi all,

As always in a discussion about EXP vs. PS, I suggest having a look at the definition of Proposed Standard, e.g., in RFC 7127:

   A Proposed Standard specification is stable, has resolved known
   design choices, has received significant community review, and
   appears to enjoy enough community interest to be considered valuable.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

   A Proposed Standard will have no known technical omissions with
   respect to the requirements placed upon it.  Proposed Standards are
   of such quality that implementations can be deployed in the Internet.
   However, as with all technical specifications, Proposed Standards may
   be revised if problems are found or better solutions are identified,
   when experiences with deploying implementations of such technologies
   at scale is gathered.

As an individual contributor to TCP and congestion control research, I believe that a CUBIC specification can meet these requirements.

Maybe the "no known technical omissions with respect to the requirements placed upon it" could benefit from some text inside rfc8312bis to make clear what the requirements are, i.e., what the standard tries to achieve (and what not). But, at least to me, the current section 5 already covers that. I am not against adding some more text on the scope of rfc8312bis, but I'll certainly not insist in that.

Also, another repetition of what I wrote already in the past:

In my observation, TCPM is extremely conservative when it comes to standards track documents, as compared to other WGs in the IETF (also outside TSV, e.g., in RTG or OPS). Probably that is not a bug, but a feature in a standardization body. And at least I have not tried to change that thinking as chair in the last 10 years. Nonetheless, if a document can meet the bar for a PS, I believe TCPM should try to go for a PS.

Michael (not wearing any hat)

> -----Original Message-----
> From: Lars Eggert <[email-masked]>
> Sent: Monday, February 21, 2022 3:52 PM
> To: Yoshifumi Nishida <[email-masked]>
> Cc: Markku Kojo <[email-masked]>; [email-masked] Extensions
> <[email-masked]>; tcpm-chairs <[email-masked]>
> Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
> 
> Hi,
> 
> first, as an editor (but not wearing other hats) I do object against reclassifying
> the document as Experimental or Informational, esp. this late in the process.
> 
> CUBIC is not a new CC proposal. It's been ubiquitously deployed on the
> Internet for many years. All major TCP stacks use it by default. Given that, I
> don't see how the IESG statement on "Experimental Specification of New
> Congestion Control Algorithms" applies here.
> 
> (As an aside, that statement was specifically written when CUBIC, Compound
> and Hamilton were all jostling for RFC publication. The community converged
> on CUBIC in the meantime.)
> 
> CUBIC *is* the default CC mechanism used on the Internet and in other IP
> networks. It should be published on the standards track.
> 
> Second, this is the second time that an individual raised a long list of issues
> after the WGLC has ended. We did try to work through all the issues that
> were raised after the first WGLC, but the individual often failed to participate
> in the discussion in a timely manner. I now see at least several of those same
> issues re-raised by the same individual. Before going down the same path a
> second time, I would actually ask the WG to confirm there is consensus that
> the raised issues are valid (and if they are valid, commit to contributing to a
> resolution in a timely manner.)
> 
> Thanks,
> Lars

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Feb 2022 11:13:22 +0000

All,

On 22/02/2022 00:11, Bob Briscoe wrote:
> Since RFC2914, we've had RFC3246 explaining why Reno is unscalable,

Sry, I meant RFC3649 "HighSpeed TCP for Large Congestion Windows" not 
RFC3246 (Expedited Forwarding)!

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 23 Feb 2022 01:16:44 -0800

Hi Bob, everyone,

I also think the points raised by Markku are valid and should be
highlighted for future work. But, at the same time, I am not sure it is
reasonable to delay producing standard docs.

What I am wondering is if it would make sense to publish these points as an
RFC to indicate "we believe they are acceptable for PS, but will need long
term analysis and evaluations as the Internet evolves."
Because we know they are a bit more aggressive than what have been done
before, but they are the feature, not bugs as Bob mentioned.
In this way, we don't have to hold the doc for a long time.

I think we can add more points in this doc, for example, initial window.
I believe we'll discuss promoting RFC6928 as a PS in the near future, but
if we apply "wide deployments and experiences are not enough" policy, it
may take a very long time while RFC9002 already allows it.
I am thinking this approach could allow us to treat IW10 for TCP and IW10
for QUIC more or less equally.
--
Yoshi

On Mon, Feb 21, 2022 at 4:11 PM Bob Briscoe <[email-masked]> wrote:

> the rfc8312bis draft. Whatever status we give the eventual RFC, they should
> be highlighted as areas that need further work, either known weaknesses or
> just areas where we don't have enough data to know whether they are
> weaknesses. I tried to help find useful references for experiments already
> done around those points, and I tried to help write such text.
>
> #1: The rules can change It's OK to quote RFCs, but it's also OK for us
> to reach consensus that certain aspects of old RFCs are outdated, as long
> as we give our reasons, and there is rough consensus around that. We are
> all consenting adults - we don't have to be limited by RFCs from the past
> if we collectively don't want to be.
>
> I have not noticed a need for the above "rule #1" in this discussion yet,
> but I'm just putting it out there, so if anyone needs to invoke it later,
> they can't be accused of inventing a rule for their own convenience.
>
> #2: There is no TCP-compatibility requirement Yes, CUBIC is not
> TCP-compatible. But that's a feature, not a bug. Words like
> 'TCP-compatible' or 'fair' sound nice, but do not be fooled into thinking
> that an RFC recommends or requires you to behave in a certain way just
> because it has used a nice-sounding word for it.
>
> what is necessary to be 'fair', it implies nothing about whether you should
> or must be TCP-compatible, or fair; unless it actually says you SHOULD or
> MUST be TCP-compatible, or fair. *No RFC says that.*
>
>        RFC2960 <https://www.rfc-editor.org/rfc/rfc2960>, RFC4340 <https://www.rfc-editor.org/rfc/rfc4340>].  Alternate congestion controllers that have a
>        TCP is discussed in Sections 4 <https://www.rfc-editor.org/rfc/rfc5033.html#section-4> and 6 <https://www.rfc-editor.org/rfc/rfc5033.html#section-6> of [RFC3649 <https://www.rfc-editor.org/rfc/rfc3649>] (HighSpeed TCP)
>        and *using spare capacity* is discussed in Sections 6 <https://www.rfc-editor.org/rfc/rfc5033.html#section-6>, 11.1 <https://www.rfc-editor.org/rfc/rfc5033.html#section-11.1>, and 12 <https://www.rfc-editor.org/rfc/rfc5033.html#section-12>
> generation of hi-BDP CCs developed at that time, as I've emphasized in the
> last para above.
>
> #3: A process for publishing EXP RFCs doesn't cover publishing non-EXP
> RFCs (by definition)
> applicable to this case. The IESG statement contains a sentence about how
> to determine its applicability:
>
> The decision of whether a specific new congestion control schemes goes
> beyond the principles of [RFC2914] and hence will undergo the process
> described in this document lies with the transport area directors, who will
> use the expertise of the transport area directorate and other congestion
> control experts to aid their decision.
>
> can debate whether the process that Markku quoted is relevant to this case,
> to help the AD to decide whether to follow the process or not.
>
> #4 EXP or STD? My view
> As I already said, we have to stop thinking that the stds track requires a
> CC algorithm to be perfect. A CC certainly mustn't have failure or collapse
> modes, but it's performance doesn't have to be perfect in all cases. For
> instance, CUBIC has known poor utilization over radio links. That didn't
> stop Reno from being on the stds track. For me, the IETF needs a new CC on
> the stds track, and CUBIC is the most natural candidate.
>
> recognized CUBIC on the stds track. That is a failing of *us* in the tcpm
> WG. We can move CUBIC to stds track via the exp track if we have to, or we
> can go straight to stds track. The only difference is that the first option
> makes us look like jobsworths for longer.
>
> jobsworth
> /ˈdʒɒbzwəːθ/
> *noun*
>  derogatory•informal

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 23 Feb 2022 07:17:07 -0800

Hi, Bob (et al.),

> On Feb 21, 2022, at 4:11 PM, Bob Briscoe <[email-masked]> wrote:
> 
> Yoshi, Markku,
> 
> Many of the technical points Markku raised were important omissions from the rfc8312bis draft. Whatever status we give the eventual RFC,     they should be highlighted as areas that need further work, either known weaknesses or just areas where we don't have enough data to know whether they are weaknesses. I tried to help find useful references for experiments already done around those points, and I tried to help write such text.
> 
> Yes, CUBIC is not TCP-compatible. But that's a feature, not a bug. Words like 'TCP-compatible' or 'fair' sound nice, but do not be fooled into thinking that an RFC recommends or requires you to behave in a certain way just because it has used a nice-sounding word for it. 
> 
> For an RFC to recommend or require something, it has to say SHOULD or MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks about what is necessary to be 'fair', it implies nothing about whether you should or must be TCP-compatible, or fair; unless it actually says you SHOULD or MUST be TCP-compatible, or fair. No RFC says that. 

RFC 5681 "TCP Congestion Control” (standards-track) says (emphasis mine below):

3 <https://datatracker.ietf.org/doc/html/rfc5681#section-3>.  Congestion Control Algorithms

   This section defines the four congestion control algorithms: slow
   start, congestion avoidance, fast retransmit, and fast recovery,
   developed in [Jac88 <https://datatracker.ietf.org/doc/html/rfc5681#ref-Jac88>] and [Jac90 <https://datatracker.ietf.org/doc/html/rfc5681#ref-Jac90>].  In some situations, it may be
   beneficial for a TCP sender to be more conservative than the
   algorithms allow; however, a TCP MUST NOT be more aggressive than the
   following algorithms allow (that is, MUST NOT send data when the
   value of cwnd computed by the following algorithms would not allow
   the data to be sent).

That looks like a MUST that defines fairness to me.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Feb 2022 18:44:23 +0000

Joe,

On 23/02/2022 15:17, [email-masked] wrote:
>> Many of the technical points Markku raised were important omissions 
>> from the rfc8312bis draft. Whatever status we give the eventual RFC, 
>> they should be highlighted as areas that need further work, either 
>> known weaknesses or just areas where we don't have enough data to 
>> know whether they are weaknesses. I tried to help find useful 
>> references for experiments already done around those points, and I 
>> tried to help write such text.
>>
>> Yes, CUBIC is not TCP-compatible. But that's a feature, not a bug. 
>> Words like 'TCP-compatible' or 'fair' sound nice, but do not be 
>> fooled into thinking that an RFC recommends or requires you to behave 
>> in a certain way just because it has used a nice-sounding word for it.
>>
>> MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks 
>> about what is necessary to be 'fair', it implies nothing about 
>> whether you should or must be TCP-compatible, or fair; unless it 
>> actually says you SHOULD or MUST be TCP-compatible, or fair. *No RFC 
>> says that.*
>
> RFC 5681 "*TCP Congestion Control**”***(standards-track) says 
> (emphasis mine below):
>
>     algorithms allow; however, a T*CP MUST NOT be more aggressive than the following algorithms allow 
> (that is, MUST NOT send data when the value of cwnd computed by the 
> following algorithms would not allow the data to be sent)*.
>

[BB] Nice point. I usually consider that requirements in an RFC mandate 
what implementers have to do to claim compliance with that RFC. But this 
one does indeed seem to be setting its reach much wider, to any 
implementation of the TCP protocol, not just implementations of this CC.

If that is how we are meant to read it, it contradicts BCP 133 [RFC5033] 
that I quoted earlier. So, I guess people will pick which one they prefer.

As far as implementation compliance is concerned, hardly any TCP 
implementation in use complies with this mandate any more. And even at 
the time it was published (2009), it already wasn't being followed by 
many/most Windows and Linux machines (Compound and Cubic were introduced 
in 2006). I notice this wording was added in RFC2581 (1999), so the 
non-compliance crept up on the IETF, and by republishing these words 
unchanged, I guess this looks like the IETF perpetuating a pious hope 
that TCPs will comply.

So, if we do make CUBIC PS, it will need to update this para in RFC5681.

Bob

---

From: Lars Eggert <[email-masked]>
Date: Wed, 23 Feb 2022 20:50:15 +0200

Hi,

> So, if we do make CUBIC PS, it will need to update this para in RFC5681.

it does so already - see the last paragraph in https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis#section-1

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Wed, 23 Feb 2022 20:51:50 +0200

> it does so already - see the last paragraph in https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis#section-1

sorry, the last paragraph on page 4 at the above URL. (Section 1 is longer.)

Thanks,
Lars

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 28 Feb 2022 02:06:52 -0800

Hi,

We've been discussing how to proceed 8312bis draft, but I think we still
haven't settled yet.
In my understanding, there seems to be the following options so far.
if you have some thoughts on them or you have other options for this,
please share.
BTW, please note that this discussion might affect our future drafts
because we want to apply the same bar for all standard docs as much as
possible.

1: Publish the draft as a non-standard doc
    a: publish as an informational doc

    b: publish as an experimental doc
        * we might need to describe what experiments are expected.

2: Publish the draft as a PS doc
    a: do additional experiments to make sure there's no concern as a PS
doc.
        * we will need to decide what kinds of experiments are required,
what would be the expected results before the experiments.
        * we need to delay the publication of the doc until the validation
of the experiments has finished

    b: publish an additional doc that describes the checking points on the
doc (and other related docs) for long term analysis.

Thanks,
--
Yoshi

---

From: Neal Cardwell <[email-masked]>
Date: Mon, 28 Feb 2022 09:29:28 -0500

> doc (and other related docs) for long term analysis.

I would argue for:

  (2) publish the 8312bis draft as a PS doc, and

  (2b) publish an additional doc that describes any aspects of CUBIC where
the community would like to see further experiments or improvements.

IMHO Michael Scharf made an excellent argument for PS status for CUBIC on
Feb 22 (
https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ )
by simply quoting a definition of PS from RFC 7127:

It seems clear, IMHO, that CUBIC meets those criteria for being named a PS.

best regards,
neal

---

From: Vidhi Goel <[email-masked]>
Date: Mon, 28 Feb 2022 11:22:38 -0800

>   (2b) publish an additional doc that describes any aspects of CUBIC where the community would like to see further experiments or improvements.
> 
> IMHO Michael Scharf made an excellent argument for PS status for CUBIC on Feb 22 ( https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ <https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/> ) by simply quoting a definition of PS from RFC 7127:
> 

I agree with Neal’s suggestion based on PS status definition from the above RFC.

Thanks,
Vidhi

> On Feb 28, 2022, at 6:29 AM, Neal Cardwell <ncardwell=[email-masked]> wrote:
> 
> 
> 
> On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> We've been discussing how to proceed 8312bis draft, but I think we still haven't settled yet.
> if you have some thoughts on them or you have other options for this, please share.  
> BTW, please note that this discussion might affect our future drafts because we want to apply the same bar for all standard docs as much as possible. 
> 
>     a: do additional experiments to make sure there's no concern as a PS doc. 
>         * we will need to decide what kinds of experiments are required, what would be the expected results before the experiments.
>         * we need to delay the publication of the doc until the validation of the experiments has finished
>        
>     b: publish an additional doc that describes the checking points on the doc (and other related docs) for long term analysis.  
> 
> I would argue for:
> 
>   (2b) publish an additional doc that describes any aspects of CUBIC where the community would like to see further experiments or improvements.
> 
> IMHO Michael Scharf made an excellent argument for PS status for CUBIC on Feb 22 ( https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ <https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/> ) by simply quoting a definition of PS from RFC 7127:
>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 28 Feb 2022 12:07:14 -0800

+1 to Neal and Vidhi's comments.

On Mon, Feb 28, 2022 at 11:23 AM Vidhi Goel
<vidhi_goel=[email-masked]> wrote:
> IMHO Michael Scharf made an excellent argument for PS status for CUBIC on Feb 22 ( https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ ) by simply quoting a definition of PS from RFC 7127:
>
>
> On Mon, Feb 28, 2022 at 5:07 AM Yoshifumi Nishida <[email-masked]> wrote:
>>
>> Hi,
>>
> IMHO Michael Scharf made an excellent argument for PS status for CUBIC on Feb 22 ( https://mailarchive.ietf.org/arch/msg/tcpm/k47hlSsx1lRupy5LRTJ5pQ6LrDE/ ) by simply quoting a definition of PS from RFC 7127:
>