Re: [tsvwg] ECT(1): Plan for Vancouver

Jonathan Morton <> Thu, 05 March 2020 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D94333A1253 for <>; Thu, 5 Mar 2020 02:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xcaZbkvAGnal for <>; Thu, 5 Mar 2020 02:47:41 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1287D3A1254 for <>; Thu, 5 Mar 2020 02:47:41 -0800 (PST)
Received: by with SMTP id i10so3780200lfg.11 for <>; Thu, 05 Mar 2020 02:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BCCX9upHAe+Sc+EPPOnC7N/tBUJW6MCiP47xb6xyMEQ=; b=kqAK9gc7rfRFt1Fr8lPu1TMQSeYeBC+R7oFIxamAsiHAOHxfI0FXj8pFYlcbXqRu49 NgBbR4chKMFyh5+GVajQKbRNVrAdGt+49IfesLbUECzTcDrV9cHfxFgwbeuNHtA70WF8 SkmzI/XMTPND2w9lx7KrtOWKpcz9Va4kpAZTX3ZJ+osdSlt46LDelCCjlleks8b93L0N CPgL1Dd5Eu5pW6IRpZsfkB3Qsz1eHlT+WVR1JKKtApun/QY/lVSjma0SsgLVayCRrepI WxMQSAq0qHvSb5EEdYxbzcDWLZCccN8u3R/hx8qoot3LsnyEROW+lsEqgQSopozum8U3 kMVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BCCX9upHAe+Sc+EPPOnC7N/tBUJW6MCiP47xb6xyMEQ=; b=Kyp/9n0AJ4TF4LI5SgbcaM/v57u81EYBqDa2BotySkC3QL52+9yJXvCV2qvqUE90RD n0ldtqSehKpELvVO7sntBWOWhYFb13NXR+bjPOhqMSkn1l2qCU7bVzrjXOJgWVr+GZnB Gcf0adAAc+bDdTqRCaOMma8+LhVt7j5eg978KoKhxNVcPPgJwqv38mYdvstQ+UoBSauk WYrO/U6xyPa6aw2+1PLKGBQ0IGDcxGf+XdAk0VHMFfO49FxMvYtajSECGj2sioxhGveT H8uWeMKiCxnZxj2Esbg0nN1tliyGetoh7R1L8tRUgxviDAUxyUUTMJEyaEPqcZ1lVuxm BdCg==
X-Gm-Message-State: ANhLgQ2v7Okif07rF+WDSKwJZYcaIK8UgjKX+hjbigY5GVa5GhBhyGAe AwEJ/cbCf0edAhQ8MWToGnA=
X-Google-Smtp-Source: ADFU+vtmM6yQFTdI7tjb5CTQ3+WoCmIbrMR1fxdXP1+eu1fgn2DnQ4qNxX6XNVnfLZkjZBR2bg5pMQ==
X-Received: by 2002:ac2:5c4d:: with SMTP id s13mr5308011lfp.128.1583405259218; Thu, 05 Mar 2020 02:47:39 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id w3sm5267515lfe.9.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2020 02:47:38 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Thu, 05 Mar 2020 12:47:37 +0200
Cc: "" <>, "" <>, Ingemar Johansson S <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] ECT(1): Plan for Vancouver
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2020 10:47:43 -0000

> On 5 Mar, 2020, at 11:42 am, Ingemar Johansson S <> wrote:
> One problem is the term "starvation". Depending on who you ask and what the
> preferences are, you are likely to get different opinions.

> The discussion I have seen on this list is more about that certain traffic
> classes are potentially treated more unfairly for a number of reasons. But
> based on how I interpret the term "starvation" I don't agree that the term
> describes the concerns. Perhaps, what is needed is to define what goes under
> "starvation". 
> To take one analogy.. Income inequality is a growing concern in Sweden (yes
> it's true also for socialist Sweden!). Still, it can't be claimed that
> people are starving, people have food on the table. 

It's an interesting analogy, though one which may provoke political rants.  Let me put the analogy in context briefly, and then put it aside.

Many economists point to a period some decades ago, before the rise of "trickle down" economics, as an example of good practice - when CEOs tended to earn about 20x as much as their front-line employees.  It's enough of a difference to reward the more skilled and those taking on risks and responsibilities, without actually sucking huge amounts of capital into a black hole where it does no economic good (because the extremely rich can only spend so much).  Today's situation, where a 200x factor is more common than 20x, is clearly suboptimal - and while not too many people are actually *starving* in Western society, there are supposedly rich countries where most people cannot afford life-saving medical care, or to take a few sick days off work (they wouldn't make rent), or to replace a bald tyre.  That's because food is relatively cheap these days, compared to these other necessities.  In places like Sweden, the situation is improved by the progressive taxation of the wealthy, to provide public services and income support for those less fortunate.

In networking, it's difficult to hold up any given traffic as being more deserving of the use of capacity than others.  This is why Fair Queuing, which enforces equality of throughput for capacity-seeking flows, is often held up as an ideal.  The next best thing, in the status quo, is equal congestion window sizes, which lead to throughputs inversely proportional to the baseline RTT when the queue is kept arbitrarily short, and converges towards equality of throughput when the effective RTT is equalised via a longer queue.

Both L4S and SCE potentially disrupt this status quo in their design, for different reasons.  What the Chairs wish to ensure, I think, is that this disruption does not severely reduce the utility of the Internet, either for existing traffic using conventional congestion control, or for the new traffic using high-fidelity congestion control.

In that sense, even if a precise threshold for unfairness cannot be agreed upon, there is clearly a qualitative difference between a system which imposes a 15-fold reduction of available throughput on existing traffic, versus one which accepts a 2-fold reduction of throughput to itself, when deployed in a shared environment without FQ.  I think when shown that way, consensus that one is acceptable but the other is not would be straightforward to achieve.

 - Jonathan Morton