Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

Jonathan Morton <chromatix99@gmail.com> Mon, 02 November 2020 00:52 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572663A0B84; Sun, 1 Nov 2020 16:52:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, URIBL_BLOCKED=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 cxy4WbWImxha; Sun, 1 Nov 2020 16:52:10 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 52AAD3A0BA3; Sun, 1 Nov 2020 16:52:10 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id m8so7105635ljj.0; Sun, 01 Nov 2020 16:52:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xOgHW4UnCQg5rS6VD+i5ChctdQSlkmtLnKxsUBK78PU=; b=V/9Ugq6hOE4tGBgCaY4/cPtomgAvyVP5po5PtO0rWXt6XoA8nK0dxdrVgUkJF8ly+M xZ82fz+MC1fUIdaDauJc1Z1ON2FSIU6ZWJ+in3LoSC3nkcM/x0LeN85aDsJPV03neta7 T7KcLGwNYkb8x+M81v3HjLo6oPZ7I+Wly/YGqOLWR6GGwMt/tzf2ZSnOSrRI6uFplttl lS5Iy54azFsM6M2xRS2oFhDfH1UvTs3O82irpijcjW7SUGjj/QlBG0zs3bV2QPpU+myS I2+u0jgIKXEDdoklRPiAu02CzrcDuadwZx+lXLznwNnbi8ywdoV//6tFmVTHTr9AtW8D Fxbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xOgHW4UnCQg5rS6VD+i5ChctdQSlkmtLnKxsUBK78PU=; b=IHJ/UonPp1q8cT7ifi0y+IxycveX9iSQWd/xMVnfPLgq7K6RMlpMzRSlMB3oDwds+7 V3wshmxs7g04pMlSiFundSJumrhELWagpevm8VPr5R8KzI0u4bJpptooBnsABfy1ArhR iWja/SlH7ge9rEcPgzuNZi5jQZbC6Rkj/h/QLpd/gIDN0OtWr3aIdYAWoHyub2Gj8izb U76zMHxgHA8kwF+ub6OuBC+HptiuJpq3BHq2PYasWe42QYebMy/ROmJFJZx6yxnBJUjF uOQVnEJndhWR/DaJo+jLR5KVVKtUKiFTiqVTPkHZHPrmEMcRMJnzybOTJWZz2OARMJZK 6WqA==
X-Gm-Message-State: AOAM5336EvpVtcBdYKysnUexCNnebSdS8CsVSB6v3oL3B4SSWeTpyDFi ztxG3t0CJNJA3Zz6lTHXdfc=
X-Google-Smtp-Source: ABdhPJxhakLehS9eCJG9/D08dOGNZaIN8iFvSfQcrahvCommSeQxzjvvBLAerDQJnrBjvvxkIcpz3w==
X-Received: by 2002:a2e:b1c6:: with SMTP id e6mr1996719lja.108.1604278328301; Sun, 01 Nov 2020 16:52:08 -0800 (PST)
Received: from jonathartonsmbp.lan (178-55-170-35.bb.dnainternet.fi. [178.55.170.35]) by smtp.gmail.com with ESMTPSA id b25sm1617776lfa.32.2020.11.01.16.52.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2020 16:52:07 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <fc6f56f1-add4-fdc0-4718-012ee10102bf@huitema.net>
Date: Mon, 02 Nov 2020 02:52:06 +0200
Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, iccrg IRTF list <iccrg@irtf.org>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <84E29EA3-67DF-4130-8E92-940D5A4B19DA@gmail.com>
References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> <28247e5f-5df3-1f75-50e6-b4a7e80d5ab0@huitema.net> <61B6E9DC-8786-4CC0-9AC0-7F74E3529A73@gmail.com> <40751956-daa0-5693-d880-c45e8ca262cc@huitema.net> <AM0PR07MB6114083DB6F3FBA98AA2281FB9130@AM0PR07MB6114.eurprd07.prod.outlook.com> <5ba51c98-9600-a55f-5d9f-bff012eb39e4@huitema.net> <fc6f56f1-add4-fdc0-4718-012ee10102bf@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/ma8UCan5YkUFr2_AjmiFqZnpMGs>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 00:52:19 -0000

> On 2 Nov, 2020, at 2:10 am, Christian Huitema <huitema@huitema.net> wrote:
> 
>> In any case, you have a scaling issue. Let's consider a 1.5Gbps link, with 15 ms delay and 1500 bytes packets. The nominal sending rate is 125,000 packets per second. The marking rate with your formula shall be p = 2/(r*0.015), which is about 0.0008%. Over the last 10 RTT, the connection will on average see 0.14 marks -- that is, no mark over the last 10 RTT 86% of the time. This falls well short of the requirement to provide frequent feedback!
> 
> Sorry, bug in my spreadsheet. The marking rate is actually 0.1%, about 2 packets per RTT. Still not frequent enough for my taste, but much better than 0.0008%. Nevertheless, the inverse relation between marking rate and data rate is not great.

A property of both Reno and DCTCP is that a particular CE marking probability results in a particular average cwnd, over some reasonably long period.  The relationship formula is of course very different for each one, but that qualitative rule happens to be the same.  It is a property that DualQ's coupled AQM design relies on.  CUBIC is a little different in its high-BDP regime, but acts like Reno otherwise.

What this means is that competing flows experiencing the same marking probability will converge to the same cwnd, and their relative throughputs will be inversely proportional to their effective RTTs.  This convergence is not necessarily very fast, but given a single queue and a single AQM, it's about as good as you can expect.

When you have an AQM per flow, you can do a bit better by applying a different marking probability to each flow.  This makes convergence faster, and you can make them converge to the same throughput, not merely the same cwnd.  When you have a separate queue per flow, you can additionally prevent one "fat" flow from affecting the latency of sparser flows, and *enforce* the throughput equality on short timescales, even with flows that are unresponsive to congestion signals.  This is all established practice.

And that is the key to achieving RTT independence with the minimum of added complexity.

 - Jonathan Morton