Re: [tcpm] alpha_cubic (was: Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03)

Jonathan Morton <chromatix99@gmail.com> Sun, 12 September 2021 18:25 UTC

Return-Path: <chromatix99@gmail.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 967FA3A1677 for <tcpm@ietfa.amsl.com>; Sun, 12 Sep 2021 11:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYChiGVoWhOV for <tcpm@ietfa.amsl.com>; Sun, 12 Sep 2021 11:25:24 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A163A1678 for <tcpm@ietf.org>; Sun, 12 Sep 2021 11:25:24 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id n2so16157545lfk.0 for <tcpm@ietf.org>; Sun, 12 Sep 2021 11:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6yGaSV0TDo2HudwZcn6xLPeGVCEl1cxRcmqnHn910uc=; b=Zz7P5IVTeF9h/6Z5DgumoSA66WHJhw1rPZ0SAdOoFn1BCCYHjnEeJOIy+1dyNb/Nqo IKfOeezCdxGic4coiAQJ0WxN2VSqyBOd7St6LYG25GmX65JoqT6wX5GndAtgU6lmSdoz GmbFU1pLLO+JsHLeshero7k7Y5GvZx/OP8uKolxb8l0J142bkgCXeFowFd7Zfle6AXz1 sBBH12zIlHRxu3oETSMK3MbJr6+XFN0XEZ5guVUMOUPehpn7l3ko9iaMI8yRpqKV1II5 hRRtPjDUOXkWwF0XPdUoJJ3vSaXYoYB5j96EX1HBbtnDU2PeR0BuQkXoLBi6fSuOPBEo KjTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6yGaSV0TDo2HudwZcn6xLPeGVCEl1cxRcmqnHn910uc=; b=7VEt+wGtWpxSctUSkGR1HmIQuTqBkfXyLrdfmRsawbrNlc9cXMRRUbHAJbmTjzvOJf IhzJC2mnPvMo494OKsP4Q2TICnC9cb0LngVkQnBuB8sSrvUGUFk3kW81LubttpZ8WCRo HsLkZcXkyEVMigQG1QCmJhDFK0fUSLlk/oIFsqlpFauNfJSWlxcHUwSixdXk0E+7XojQ gq8+CGPwFxNuu62O6gQwjU9c5jRgvv2hykNHzuHsWEpGQP5g7MreLVAnwgepOj7dSV+u 55WDm2PqXTw8lqADlSES7eMRIZG970PF+xOcuYNHRn5ilFvH9l95Z+Q/Q19u/1aKv9Hd ntAg==
X-Gm-Message-State: AOAM530//rq8UxQBNMbgkZMM33uyTPU2AH/69wSuCun8qO+7nNWuIH3b Pb9BmLF3jDg6qePJMdQbfIg=
X-Google-Smtp-Source: ABdhPJyCb94f70MX4+gA79zwdlM5HRFPpytxjIXyvDkV9pOM8R+JltFWfkrb2jRxlz9vy/VNigS+hA==
X-Received: by 2002:a05:6512:2e8:: with SMTP id m8mr379105lfq.172.1631471121050; Sun, 12 Sep 2021 11:25:21 -0700 (PDT)
Received: from smtpclient.apple (188-67-152-209.bb.dnainternet.fi. [188.67.152.209]) by smtp.gmail.com with ESMTPSA id t15sm669657ljh.7.2021.09.12.11.25.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Sep 2021 11:25:20 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <CAAK044T-ZtZUuq4xBSuB1E9aqHOn96orXe=8ZMJHao_j4xpK3Q@mail.gmail.com>
Date: Sun, 12 Sep 2021 21:25:19 +0300
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A05E2E9-96E4-4B7E-908A-A5D780179D6D@gmail.com>
References: <CAAK044SjMmBnO8xdn2ogWMZTcecXoET1dmZqd6Dt3WzOUi359A@mail.gmail.com> <alpine.DEB.2.21.2108300740560.5845@hp8x-60.cs.helsinki.fi> <ccfc4dc2-0570-1ba2-66a5-b5e199f11359@bobbriscoe.net> <CAAK044T-ZtZUuq4xBSuB1E9aqHOn96orXe=8ZMJHao_j4xpK3Q@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/WvYxYH4upQuD3iAxTLB6knrXS6c>
Subject: Re: [tcpm] alpha_cubic (was: Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 12 Sep 2021 18:25:28 -0000

> On 12 Sep, 2021, at 12:02 am, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
> 
> The first point is about RTT variation. 
> I think you have a point there, but I personally think the paper presumes very shallow queue so that the model can be very simple.
> In this case, we don't have to think about min or max of RTT as they will be mostly the same.
> I think we can probably argue the accuracy of the model, but I think it is too broad as a scope of this document. It looks a very deep research topic to me.
> I think the model is basically derived from Equation-based Congestion Control paper in sigcomm 2000. If we want to update or renew it, we might need another RFC5348. 
> So, I think it would be better for this doc to use the model as it is and leave its enhancements for future discussions.

I think the assumption of constant RTT will become increasingly valid as AQM is deployed, so this was a good and prescient simplification by the authors.  The alternative scenario of a relatively large drop-tail buffer can be checked empirically for reasonable behaviour, if required - but the existing wide deployment of CUBIC suggests that any serious trouble would already have been noticed.

> The second point is α in the draft might be too big. 
> During my WGLC review, I read [FHP00] once and I had similar thoughts.
> But, after I re-read the paper several times, I start having a different interpretation. 
> 
> First off, it is very clear that β=0.7 is more aggressive than β =0.5 when there's no other traffic.
> As cwnd growth is linear, if there's enough long time for the data transfer, the average cwnd for β =0.5 will be (1.0 + 0.5)/2 = 0.75 Wmax and it will be (1.0 + 0.7)/2 = 0.85 Wmax for β=0.7. 
> So, it is obvious that this model does not aim for the cases where there's no other traffic.
> 
> I believe the choice of (α,  β) in [FHP00] is designed to be more or less fair only when it competes with (α=1.0,  β =0.5)
> Hence, I think we should not apply the loss rate for no-other-traffic situation to the formula, which can lead to α3 = 0.20

That was definitely the impression I got, too, and in fact it puzzles me why anyone would assume otherwise.

Another point to note is that this entire calculation is only valid in the "compatibility" regime of CUBIC, where it is explicitly attempting to perform similarly to NewReno.  If a test scenario drives CUBIC into its "native" regime where the polynomial curve rises above the linear growth function, then it will outperform NewReno by design.  The assumption then is that NewReno is insufficiently utilising available capacity, so there is less concern over causing harm to it and more advantage to using that leftover capacity.

 - Jonathan Morton