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

Ian Swett <ianswett@google.com> Thu, 13 October 2022 10:48 UTC

Return-Path: <ianswett@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 591C6C1524CE for <tcpm@ietfa.amsl.com>; Thu, 13 Oct 2022 03:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Level:
X-Spam-Status: No, score=-17.609 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 05vi0A2ujFQj for <tcpm@ietfa.amsl.com>; Thu, 13 Oct 2022 03:48:07 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 8EF0EC1524CF for <tcpm@ietf.org>; Thu, 13 Oct 2022 03:48:01 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id c9-20020a05600c100900b003c6da0f9b62so1193333wmc.1 for <tcpm@ietf.org>; Thu, 13 Oct 2022 03:48:01 -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:message-id:reply-to; bh=O7vBfk8n1ZL4BCSkHj4zHLH2elkfiE2Mtf96tMkY+Jc=; b=L3NKWpMfMPbpgMjP5bXn2jDC3hoDfchMxwFsGAUyIyjK4/vpYq7bU7HWlYBEeAC0VR 7yVUN/zWM6NbU5Y6PR0e2LC0MkCev0jjIL0L/bPNlAGa0rQtkiZ0f4FofiqWdb0HeXgX SS8emkbVKGNbUQCEsfcFEeux054hY4dkjzl4IlPo6dn7cCH/eB90eBa30LbtdrNz6pSc Cp48jNDTYnGbFCmm8qBDX62TEjQIRrDIhU9oXsGaC7oxocgXYCSqGCRlG5pMiyaki8Fg +MV1tjqOW2UgYnkI91KbzpfhryzEQZv6/l2fYg23UBdIZI5TDY44CCDZx0FKJVGgof78 bNyA==
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:message-id :reply-to; bh=O7vBfk8n1ZL4BCSkHj4zHLH2elkfiE2Mtf96tMkY+Jc=; b=jA3lwmC2FH2waBwB3A1KY2XUKzepvFoPBe7x2icytILeD3sx8A0UwK+xFVhqdc4DVL JaJDeMyERVu9Putz6l4xSwdQlQz8I9FCox5MSpiEJ8V8k1qYxQy6mDFeUrrBrplZsXia d2sUumGlvBqk3EFil+9Sp19OKjGW+BSqlV4dpQxVqyodzCRWcKxpq/YRqs7hlaTipO1z 1Y0TxHAIgESYtJPd9HN42AjacULBcis3wXqlKXMae3Lv6UhySBkzOf9hPbkkVVz6NqU3 i8mHXqLw/F0qMkVn92Fzzl1ZaOtUQbhlTIDbr/hmqRPoJQCccIHio2xhK7DTOxYkLVZu 1aUQ==
X-Gm-Message-State: ACrzQf2Ff4lB+YEuTzSHYcEXZPkDnA7Ox+/KhVrdIY+G7dYxsbj8WVpB PulkHFZBAMcKmV/pJEftK3WszD8TvRDWdlY8xXG0zg==
X-Google-Smtp-Source: AMsMyM4I1waQvjClMtVt49OzhQy2YmJYtEUwCvxxce62d5sO8vKiJfBQmY5hNEXlWE+d4lD2wrvyDsGV/TtY9T4C9Q4=
X-Received: by 2002:a05:600c:4e52:b0:3b4:a828:1d84 with SMTP id e18-20020a05600c4e5200b003b4a8281d84mr5754852wmq.143.1665658079219; Thu, 13 Oct 2022 03:47:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAAK044QnUTW3Zr5sBZ3wv5e0A=q2OGdooHSZHAKRHmo5qMrSkg@mail.gmail.com> <alpine.DEB.2.21.2209120201550.5586@hp8x-60.cs.helsinki.fi> <CAAK044ResprcmpgEmtvR+0wVKri2OfnDcJQH4SD+pwaevdWRNw@mail.gmail.com> <alpine.DEB.2.21.2210100159000.4174@hp8x-60.cs.helsinki.fi> <86AD67E1-13EC-48C5-AAEF-71E2163DD1F7@gmail.com>
In-Reply-To: <86AD67E1-13EC-48C5-AAEF-71E2163DD1F7@gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Thu, 13 Oct 2022 06:47:47 -0400
Message-ID: <CAKcm_gPhbm+ZkD+q3qN9bMWrZYc6KiSBJXv0A3t_wuVNoeMmSw@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021925305eae83e3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/whjePH092Gv9Cv00uZrjFoqdp_s>
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: Thu, 13 Oct 2022 10:48:08 -0000

Taking my chair hat off for a moment.


IMO the question should be whether deploying Cubic has or will cause
measurable harm on the public internet vs Reno.  I have never seen evidence
of this because I think it's so rare it's in practice unmeasurable.

Unfairness is only a problem if it's causing latency or drops to other
flows (aka externalities).  If you're running a very unfair congestion
controller on a dedicated link and it's the only flow, there's no harm.  If
the flow is constantly app-limited or never exits slow start (the vast
majority of flows), convergence in congestion avoidance is irrelevant.  How
it exits slow start actually ends up mattering more, and Cubic recommends
Hystart++.

Ian



On Thu, Oct 13, 2022 at 6:09 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > On 11 Oct, 2022, at 1:13 pm, Markku Kojo <kojo=
> 40cs.helsinki.fi@dmarc.ietf.org> wrote:
> >
> > We cannot have evidence if nobody has done any measurements. The impact
> to other coexisting traffic cannot be observed without *measuring* it.
>
> On this point, I have prepared a "neutered" version of Linux CUBIC called
> LINEAR, specifically to explore this topic.
>
> Essentially LINEAR is CUBIC, but with the polynomial growth curve removed
> so that it always operates in Reno-compatible mode, and with the facility
> to be easily configured (currently at compile time) for different values of
> beta (and the corresponding value of alpha).  Other features such as
> HyStart are still present, as they are relevant to dynamic performance when
> exiting slow-start.
>
> Currently we have the following variants which can be instantiated and
> intermixed freely:
>
> - LINEAR-A with beta=0.5, simulating NewReno plus HyStart.
>
> - LINEAR-B with beta=0.7, simulating the Reno-compatible mode of CUBIC.
>
> - LINEAR-C with beta=0.85, the most aggressive value permitted by RFC-8511.
>
> Other values could easily also be tried if desirable.  In each case the
> corresponding alpha value is computed as per the RFC-8312 formula.  The
> baseline code was taken from Linux 5.10, so might not reflect the very
> latest fixes.
>
> Pete Heist and I expect to conduct various tests on their performance and
> interaction in the near future, exploring both static (steady-state
> congestion avoidance) and dynamic (exiting slow start, step changes in
> channel capacity, start-up and shut-down of competing flows) behaviour.
> Various path characteristics, particularly baseline RTT and queue type,
> will undoubtedly be relevant for testing.  We should be able to use the
> "harm metric" to quantify effects on competing traffic, again using a free
> choice of congestion controls.
>
>  - Jonathan Morton