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

Yuchung Cheng <> Thu, 29 September 2022 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FDE7C1524CE for <>; Wed, 28 Sep 2022 17:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.607
X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Pc7Uvh1-BCl for <>; Wed, 28 Sep 2022 17:04:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 8B97EC14F692 for <>; Wed, 28 Sep 2022 17:04:43 -0700 (PDT)
Received: by with SMTP id bq9so22102094wrb.4 for <>; Wed, 28 Sep 2022 17:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=6W40elQXPlQ7KXUrYCTjRMlskHs7p2O385nySeQPAus=; b=dppwPvPoAgVILR/dkmB3y5Ut08OqDh2vk42UY6x+TVf9r3hdEbvBjBVpPQZnwjZ+LF IUGW6Ve7btxltaU39WAoeYAcXLJDVMFRvk8Hzi6fDIK4ZVGwNCot7RwF/jfYxsZcMWRb hEpdoUA5hxinJ8GgwFU4macWp5Wuw7jpibMt6aCihofxvSuFVjoNKZiFCo4Cem4faPgL WIFKfJ6LLsxi7t7wJBkb4U7OHzQI3Hq6jmyjlbSm20oPbqLyb1QxpUUidU72CuXbzCed o+0TSJ1M9EFm8CASy5oCiIRepoxddIrga2w0rSok2mGpsQIpd0K0q6pjdf15c8nxvTu6 sI2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=6W40elQXPlQ7KXUrYCTjRMlskHs7p2O385nySeQPAus=; b=NIhPrkG2g+5oCOlGYUyEPfNiLxfUFZV7G2ahQLOlQMxBolE5UYaZMEa4hxC++rOvMo 38zIxpsV3aMMQ3vHs9RkCuvETDwrHVWe7x9bEWPiX+8XkjjTcR42VA+d/dfswixJFBaU 6EWGhyKkt0gfoDZqIhPFuxwETzfWbiOL+P0w193Fvyn2CP9Qz/p7Tw2aj4SYWgU5Kc0c kKXYcWRP+KfnKSIGQlwkFsPC5KERKgDkOswuMiMTV1rhcdm/dJHXxbHzQ8sPDWQJV3Xh MYWCcuBG1qvVWJ9NRV3KjPMCW3Dxcp0BAfyGsVxtQyucbGyHBSIMPfhfEXBd7HCNska0 JVrg==
X-Gm-Message-State: ACrzQf09LB7Kc2wm9qsx1QlSCscEVsf+5mA9EeFfQTxOMQSo0V3HdmEk bVyMufkjuc7K5sUNd5i2sWOxeJjhu3aPN5mVAHGBjoeMf8vLZQ==
X-Google-Smtp-Source: AMsMyM6fACFzmdrHPINChfOnJG5mKC2018T280hmebaRjaH17FkRWoq0e0BvaNtyePUTXXHn0OyjdfdU23GrluunBS4=
X-Received: by 2002:a5d:47a6:0:b0:22a:3764:cdfa with SMTP id 6-20020a5d47a6000000b0022a3764cdfamr194003wrb.547.1664409881616; Wed, 28 Sep 2022 17:04:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Yuchung Cheng <>
Date: Wed, 28 Sep 2022 17:04:05 -0700
Message-ID: <>
To: Yoshifumi Nishida <>
Cc: Markku Kojo <>, " Extensions" <>, tcpm-chairs <>
Content-Type: multipart/alternative; boundary="000000000000c1bbc805e9c59f1f"
Archived-At: <>
Subject: Re: [tcpm] finalizing CUBIC draft (chairs' view)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Sep 2022 00:04:47 -0000

On Tue, Sep 27, 2022 at 3:09 AM Yoshifumi Nishida <>

> Hi Markku,
> Thanks for the comments.
> On Sun, Sep 25, 2022 at 6:17 PM Markku Kojo <> 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

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