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

Neal Cardwell <ncardwell@google.com> Wed, 07 September 2022 15:50 UTC

Return-Path: <ncardwell@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAEEC15A72B for <tcpm@ietfa.amsl.com>; Wed, 7 Sep 2022 08:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.605
X-Spam-Level:
X-Spam-Status: No, score=-17.605 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5F7cXa8kC58 for <tcpm@ietfa.amsl.com>; Wed, 7 Sep 2022 08:50:40 -0700 (PDT)
Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) (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 ietfa.amsl.com (Postfix) with ESMTPS id C1408C14F718 for <tcpm@ietf.org>; Wed, 7 Sep 2022 08:50:33 -0700 (PDT)
Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-127f5411b9cso5701044fac.4 for <tcpm@ietf.org>; Wed, 07 Sep 2022 08:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=1VADlwuSP+wCx3IlShrppz/JiVW85Ao/iTcfsvxJDTA=; b=lca8VAjdHsdqUEwnyDPlcunfOQlwLGwgui/A21/R48nhRnWDfvWi+BHqn69UPzv5hV hTd1Sdk7nDgMjLAGAJJRX1sjE/QLYz3ZznN6PHYiLSSslV+1mYtsSSzrFDHjwR3aWhCV JU6UBWe+CyDsW3aMo71FppvaLQ+Tuv0wKFbI3aio/dVONFaASGDMG5EVUd1iGSywMT11 /Ge4MQmv/l9MRuwMu8nM8AuGlQBJYu178OCBeubdzxeNPE3wts3y5pZfCpXd820mTMgq 76PMllPpZ+rfSFdAeJQBfGP9tuQunGxJEubnzVK8qo4+tYuZmTf28NrfP2+pZbRCO6cB 6e3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=1VADlwuSP+wCx3IlShrppz/JiVW85Ao/iTcfsvxJDTA=; b=EPX13OYBmPPqHarJ+lFpdQ1mMC/lQUHP6ObL5B7O6TYSZQNf2H7+LaSuBIzT12uvW+ oUzvu1riZX8MIsXAD6UveZoJP7qBYIBLY5Tnn9y9Up+IkObivqoeZXhZHWyquYRWSxd7 7ALGKLQREbdzVRXw31B5eVeTS/QV5P96i7pZMYmTrDtKN078guywceiUQU0aIYEx37fh MgTPrEAitF2jpi79wM7SD4oV+1FrNkXNU+CsYdK3SYCjeU/5D2q4BWqG8q64ouH2c0Ow dTc0Un0GYlNMtkUOTfwRrwcJgAQfwGe25iegCdF1Q1cMVCpzbTX0HQaw9Y3jiuddgAEW bv2w==
X-Gm-Message-State: ACgBeo0xLTPbs+Ndy3kem+e3I4mUaR0im6MJAWvIlCrlOXnh7sLhbahi ZyCNxiHGLfgMXV8xMtAhZkI/HzaijSwG90/rk420Wg==
X-Google-Smtp-Source: AA6agR4XPNFsIHYUzRUpMyQ7zTqZ3guUxXJ7OmgUNpODGPzZu68q3XwTrfRkljqIFHYatuSXenjYpXTUeUMKcIBqJy0=
X-Received: by 2002:a05:6870:3127:b0:11c:8c2c:9015 with SMTP id v39-20020a056870312700b0011c8c2c9015mr14283100oaa.31.1662565832869; Wed, 07 Sep 2022 08:50:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAAK044QnUTW3Zr5sBZ3wv5e0A=q2OGdooHSZHAKRHmo5qMrSkg@mail.gmail.com> <CAAK044TMHQo1Rfy1_6Yms1_tT3hKmKBJBeA9Qu5_r85df4xkKw@mail.gmail.com> <34786894-6F94-49E9-B733-0FAFFC5C977D@apple.com>
In-Reply-To: <34786894-6F94-49E9-B733-0FAFFC5C977D@apple.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Wed, 07 Sep 2022 11:50:16 -0400
Message-ID: <CADVnQykUDM1fsbs=Xyy1Mr1WeOTm4cV+pvagHxp=hQTPyFBEoQ@mail.gmail.com>
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2c2cd05e81845e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/CZiRc9SbYwu8B2cAA0Yf4YM91aY>
Subject: Re: [tcpm] finalizing CUBIC draft (chairs' view)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2022 15:50:44 -0000

On Tue, Sep 6, 2022 at 7:46 PM Vidhi Goel <vidhi_goel=
40apple.com@dmarc.ietf.org> wrote:

> Hi Yoshi,
>
> Thank you for summarizing the last two remaining issues.
>
> 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.
>>
>
> It’s not that the model is not valid at all, but it is not very precise.
> Copying a part of Bob’s response for this issue:
>
> *Summary: so far we show that the model that was used to calculate the
> cubic_alpha value of 0.53 is not absolutely precise, but it gives equal
> rate flows to a good approximation (within about 10% from analysis and even
> closer in experiments over an AQM). So it is extremely unlikely that there
> is any danger to the Internet here. Even if you believe flow equality is
> critical, this is in the noise.*
>
>
>
> Do you think we should add some text similar to above? We can reference
> Bob’s paper if it is already published.
>

Sounds good. A stab at some possible text:

---
The model that was used to calculate the alpha_cubic value here is not
absolutely precise, but analysis and simulation[1], as well as over a
decade of experience with CUBIC in the public Internet, show that this
approach produces acceptable levels of rate fairness between CUBIC and Reno
flows, in practice.

[1] https://raw.githubusercontent.com/bbriscoe/cubic-reno/main/creno_tr.pdf
---

In addition the draft could change "which achieves the same average window
size as Reno" to be something like "which achieves approximately the same
average window size as Reno in many cases".


>
> 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.
>>
>
> There is text already covering this. But if you think we need to add more,
> let us know.
>
> Multiplicative decrease section
> *A side effect of setting βcubic to a value bigger than 0.5 is slower
> convergence. We believe that while a more adaptive setting of βcubic could
> result in faster convergence, it will make the analysis of CUBIC much
> harder.*
>
> Slow start section
> *Whichever start-up algorithm is used, work might be needed to ensure that
> the end of slow start and the first multiplicative decrease of congestion
> avoidance work well together.*
>
> Once I hear from you, I can create pull requests for these two, if changes
> are needed.
>

IMHO these two sound like nice steps forward, and worth creating pull
requests.

Thanks, Vidhi!

neal



>
> Thanks,
> Vidhi
>
> On Sep 5, 2022, at 11:13 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
>
> Hi folks,
>
> We're looking for some feedback on this to finalize the CUBIC draft.
> Based on the previous discussions, I am thinking that one way to proceed
> is to add some explanations (not a solution!) for the points below in the
> draft.
> If you have some proposed texts on this point or you have different ideas,
> please let us know.
> If there's no opinion, I might propose some texts for them.
> --
> Yoshi
>
> On Fri, Aug 26, 2022 at 12:40 AM Yoshifumi Nishida <nsd.ietf@gmail.com>
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>