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

[Yoshifumi Nishida <[e-mail]>]

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