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

[Yuchung Cheng <[e-mail]>]

On Tue, Sep 27, 2022 at 3:09 AM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi Markku,
>
> Thanks for the comments.
>
> On Sun, Sep 25, 2022 at 6:17 PM Markku Kojo <[e-mail]> wrote:
>
>> 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.
>>
>
> From my point of view, this point is also trying to point out some
> characteristics in the model as issue 2.
> We've already mentioned that the model is not very precise and will need
> more analysis in the current draft.
> I am not very sure how this can be a serious risk for the internet yet,
> hence I think what the current draft describes is fine.
> I think we will need to see some evidence to validate if this is a
> real issue.
>
>>
>> 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.
>>
>
> Hmm. sorry. I am not sure which point you're referring to. Can you provide
> a link for github?
>
>
>> 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.
>>
>
> OK. just in case, I would like to clarify that Bob's analysis is one data
> point for further discussions.
> We can continue discussions on the analysis, but the discussions won't
> affect the draft.
>
>
>> 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.
>>
> Should we read a 22 years old RFC on congestion control to theoretically
conclude a once-in-blue-moon congestion collapse, or look at the current
working Internet that runs a lot of Cubic of 0.7 beta.

I completely disagree beta=0.7 will cause congestion collapse. Can we move
forward with rough consensus and recognize not every RFC needs LGTM from
all.


>> 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.
>>
>
> I personally don't think MD=0.7 will cause congestion collapse as I
> haven't seen such evidence so far.
> It can delay the convergence time and it's already explained in the draft.
> If you think MD=0.7 can cause serious problems such as congestion
> collapse, could you elaborate?
>
> Thanks,
> --
> Yoshi
>
>
>   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
>> >
>> >
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>