Re: [tcpm] finalizing CUBIC draft (chairs' view)

[Markku Kojo <[e-mail]>]

Hi Yoshi,

catching up ...

I wonder why the Issues 4 and 5 that were not mentioned on the mtng 
slides have not been discussed on the wg list at all nor concluded? I 
sent the detailed description of the Issue 4 to the wg list on July 29th.

Issue 5 has been discussed in github. The major problem there is that 
by following the current advise in the draft with a TCP sender results 
exactly to the incorrect behaviour that Neal pointed out in github and 
that has been (partially) corrected in the Linux TCP stack (*). In 
addition, applying UNDO cwnd opens the security threats described in RFC 
3522 and RFC 3708. There is no single word on this in the Sec 6 for 
Security Considerations? Note that the security ptoblems described in RFC 
3522 and RFC 3708 become enabled only if one applies UNDO cwnd.

(*) The problem with RFC 3522 is that it did not consider SACK at all 
(silently assumes SACK is not enabled) and therefore works incorrectly if 
applied as specified when SACK is enabled. The fix for Linux that Neal 
pointed out seems to behave similarly for both SACK and non-SACK sender. 
That would make a non-SACK sender to behave against the basic idea of RFC 
3522 that avoids further unnecessary retransmissions after the first 
retransmismitted segment, the most important advantage of RFC 3522.

I'm also afraid that Bob's analysis for Issue 1 with a tail-drop router 
is incorrect. I'll send a separate reply for that.

For Issue 2 Michael and Neal have agreed that the problematic behaviour 
occurs. I have not seen any other replies with technical arguments.
Michael explains that the problem does not occur always like I described. 
That is true but it does not mean the problem is non-existing. Instead, 
it occurs when the bottleneck router has queue of size 1 BDP or larger, 
i.e., relatively often (I'll clarify this a bit more with a reply to 
Michael). 
Neal's major argument for not using beta = 0.5 in slow start was because 
it has been deployed as beta=0.7 and changing it to beta=0.5 would 
require research. Some others have also thought it requires research.
This is quite odd given that TCP has worked with beta=0.5 since late 80's 
and there are already tons of research and experince over several 
decades with beta=0.5 when in slow start. What is the further 
analysis and evaluation that would be needed?
In addition, Beta=0.5 in slow start is also the current draft standard, 
so the correct question for the wg is why to change beta=0.5 to 0.7 and 
what is the justification for the change (and why is such justification 
not written down in the draft)?

I'm also confused about the statement that the Issue 2 may just cause 
more losses and an additional round of recovery. That's simply to point 
of view of a CUBIC flow and fully ignores the impact to the other traffic.
It is a severe violotion of congestion control principles to inject 
unnecessary packets (undelivered packets) to the network. Please see the 
description of congestion collapse in Sec 5 of RFC 2914 due to 
undelivered packets and explain why the overload of up to 40% undelivered 
packets when applying beta=0.7 in slow start is not creating congestion 
collapse (of some degree)? By this far nobody has explained or argued 
otherwise. I think this is the most serious issue with the draft.

In order to make progress with the draft, these issues must not be 
ignored IMHO. If the wg decides to publish the draft without addressing 
the issues, at minimum the facts with the issues must be appropriately 
documented in the draft.

Thanks,

/Markku

  On Fri, 26 Aug 2022, Yoshifumi Nishida wrote:

> Hello everyone,
> Based on the feedback from the last meeting, the chairs have been discussing how to finalize the cubic
> draft.
> The below is our current view on the draft. 
>  
> The slide for the CUBIC draft from the last WG meeting listed 4 discussion points in the draft. 
> > https://datatracker.ietf.org/meeting/114/materials/slides-114-tcpm-revised-cubic-as-ps
> 
> In these items, we think that the last two points are already addressed now.
> With regard to the remaining two points, our views are the following.
> 
> Point 1: TCP friendly model in the cubic draft 
>      We can admit that the model is not valid as the paper describing the model uses some simplified
> presumptions. 
>      But, it doesn't not mean the model will pose serious issues on the Internet as we haven't seen any
> evidence yet.     
> 
> Point 2: Multicative decrease factor during slow-start phase
>      We think using the current value: 0.7 may cause more packet losses in certain cases, but it can
> work efficiently in other cases.
>      We think this is a part of design choices in CUBIC as we haven't seen any tangible evidence that
> it can cause serious problems.
> We concluded this will require more detailed analysis and evaluations which can take a longer time. 
> Based on this, we think these points are NOT needed to be addressed in the draft while it will be good
> to add some more explanations for them. 
> We saw there were several opinions about documenting these points in the draft during the last meeting.
> If you have some suggestions here, please share your opinions.
> 
> Please note that this doesn't mean we'll ignore them. we will try to publish a new version of the CUBIC
> draft if we find some things on them. 
> 
> If you have any opinions or comments on the views, please share them with us.
> 
> Thanks,
> --
> Yoshi on behalf of tcpm co-chair
> 
>