Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up

[Markku Kojo <[e-mail]>]

Hi Gorry, all,

Catching up...

Thanks for the proposed text. I had a bit hard time to understand why 
this text is proposed. Then I listened to the mtng audio recording and 
heard what Lars thought was the issue. Lars has fully misunderstood that 
my issue would be that the process was not followed. It is not.

The problem is that the CUBIC algorithm has a number of unresolved 
issues (as a result of not following the process). The issues were 
raised for the WGLC and for the 2nd WGLC I listed the unresolved issues 
with some new points revealed during the discussions and after a bit 
closer consideration.

These issues are significant and some number of people have also said 
they should not be left unaddressed. Almost all of them are related to 
the behaviour of CUBIC in the TCP-friendly region where it is intended 
and required to fairly compete with the current stds track congestion 
control mechanisms. The evaluation whether CUBIC competes fairly 
*cannot* be achieved without measuring the impact of CUBIC to the other 
traffic competing with it over a shared bottleneck link. This does not 
happen by deploying but requires specifically planned measurements.

This said, I agree with Gorry that the text he proposed should be
incorporated before proceeding the doc. However, I cannot see how
widespread deployment experience can be considered to be sufficient
when it does not involve any measurements on the impact of CUBIC to the
other traffic? That is, IMO this piece of the text is not quite rational.
Quite contrary, the papers cited have evidence not supporting the intended 
behaviour gets realized but show the opposite, likewise some other papers 
not cited do.

One major problem is that the issues have not been discussed on the list. 
IMO it is must before proceeding the doc. I regret that the process got 
even mentioned because that took the discussion into the side tracks away 
from the actual issues.

For the 2nd WGLC I linked the issues with the draft to the github issue
numbers which was probably not helpful at all to initiate discussions on
the list unless one had closely followed the issue discussions in the
github. I try to briefly summarize the issues below and suggest starting
discussion on each of them in a separate thread, which I can initiate.

IMO the wg should understand and decide separately how to proceed with
each of the issues. At minimum each issue must be clearly documented in
the draft and the wg should come up with a justification for each issue
why the doc can be published despite of the issue (unless the issue is
resolved).

In addition, the text in the draft about updating RFC 5681 is very vague. 
First, it does not make it clear what updating even means: whether it 
requires anyone implementing the basic CC algos in RFC 5681 to follow 
the algos in this draft where they differ, or only allows CUBIC algo to 
diverge from the current std CC algos. Second, all differences and 
justification for them must be separately documented.


Summary of the unresolved issues:

1 a) The model/formula used for the Reno-friendly region hos not
      been validated and has actually been shown to be incorrect.
      There is one validation attempt in the original paper
      manuscript and that failed (and the manuscript never got
      published).

   b) The validation of the heuristic in CUBIC that is used to
      decide when to shift from the Reno-friendly region to
      the "genuine" CUBIC mode is insufficient.
      That is, the constant C has not been validated properly
      in vide range of environments (there appears to be nothing
      after publishing the the original research paper).


2) CUBIC is specified to use incorrect multiplicative-decrease factor
    for a congestion event that occurs when operating in slow start.
    This is badly in conflict with the original theory and design logic
    by Van Jacobson and may easily result in some degree of congestion
    collapse due to injecting excess "undelivered packets".


3 a) The rule for changing alpha to 1 when Wmax is reached in the
      Reno-friendly region is the correct thing to do during the normal
      steady state. However, it is incorrect action to take when in the
      fast convergence mode within the Reno-friendly region because it
      would act just *opposite* to what CUBIC should do when in the fast
      convergence mode; instead of slowing down the increase rate during
      congestion avoidance it actually accelerates because alpha becomes
      increased to 1 earlier than when not in the fast convergence mode.
      This seems an obvious mistake with the quite recent modifications
      to the rfc8312bis.

   b) Wmax needs to be set differently for a congestion event arriving
      when in slow start and when in congestion avoidance (the co-authors
      who are the original developpers of CUBIC have agreed on this).


4) CUBIC decreases its sending rate (much) slower than Reno CC when
    sudden congestion is encountered (or network capacity is reduced).
    The draft states this explicitly (slow convergence) but does not
    identify it being unfair as shown in the paper [PFLDNeT'07] that
    Bob pointed out. Instead, the draft just mentions it as if it
    would be Ok.

[PFLDNeT'07] Leith, D. J.; Shorten, R. N. & McCullagh, G. "Experimental
evaluation of Cubic-TCP" Proc. Int'l Wkshp on Protocols for Future,
Large-scale & Diverse Network Transports (PFLDNeT'07), 2007


5) If someone implements detecting false fast rexmits and applying undo
    of cwnd as currently described in the draft it results exactly in
    the incorrect behaviour that Neil pointed out Linux had had for a
    decade or so before it was patched (see github issue #90). That is,
    the draft must not provide incorrect advise but explain if there
    are known problems with current RFCs it cites. In addition,
    implementing undo of cwnd enables the security attacks that the
    cited RFCs discuss. Note that applying just the cited detection
    algorithms does not enable the security threats but they become
    enabled only if undo of cwnd is applied.


6) Flightsize: The current text is fine except that it does not quite
    correcly reflect what stacks that use cwnd instead of flightsize
    actually do. AFAIK and what was discussed in github all stacks
    apply some sort of restrictions to not allow cwnd to grow beyond
    rwnd and do not to use an arbitrarily high (old) cwnd value to
    calculate new cwnd when a congestion event occurs.


Best regards,

/Markku

On Tue, 24 May 2022, Gorry Fairhurst wrote:

> I'll start by saying again that I think it is important to see this 
> published as a PS (as others have noted), but I still think it needs 
> additional text to say the process differs from the recommended IETF 
> process and evaluation. I don't see how this will proceed without that 
> text in some form as discussed at the IETF-113 meeting.  Alas, I also do 
> not think highlighting this only in the Shepherd write-up, just 
> postpones this as a discussion item to the IETF-LC, which can't be a 
> useful thing to do.
>
> I promised suggested text - but was unable to work on this after the 
> meeting - sorry - so here goes, this is what I suggest:
>
>
> "RFC 5033 provides the current BCP guidelines for the community, 
> describing what type of evaluation is expected by the IETF to understand 
> the suitabiliuty of an alternate congestion control, and the process to 
> enable a specification to be approved for widespread deployment in the 
> global Internet. The present document does not update that IETF BCP.
>
> However, in the case of Cubic, there has been widespread deployment 
> experience over a considerable period (4 years since publication of RFC 
> 8312). This experience was thought to be sufficient to allow this 
> publication as an IETF standards-track specification.
>
> There are areas in which the specified method differs from the 
> previously method specified in published RFCs, some of which have been 
> highlighted in this document. As a part of maintaining the congestion 
> control document, future IETF work is expected to evaluate these 
> differences and will if necessary update the relevent specifications."
>
>
> This is not aimed at changing anything in the cubic algorithm, but it is 
> aimed at explaining why this spec did not conform to the process, and 
> seeking to avoid setting a precedent for future methods - which I really 
> think do continue to need to be evaluated in public both by researchers 
> and developers at the IETF.
>
> Whether in future the IETF updates the BCP represented by RFC 5033 is 
> another topic;-).
>
> Best wishes,
>
> Gorry
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>