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

[Markku Kojo <[e-mail]>]

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. 
> 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 <[e-mail]> 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, [e-mail] 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
>       > [e-mail]
>       > https://www.ietf.org/mailman/listinfo/tcpm
>
>       _______________________________________________
>       tcpm mailing list
>       [e-mail]
>       https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
>