Re: [tsvwg] path forward on L4S issue #16

Jonathan Morton <> Wed, 17 June 2020 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB3C83A0859 for <>; Wed, 17 Jun 2020 06:59:09 -0700 (PDT)
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 TnPacnAk29VP for <>; Wed, 17 Jun 2020 06:59:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54E393A087B for <>; Wed, 17 Jun 2020 06:59:08 -0700 (PDT)
Received: by with SMTP id c17so2955996lji.11 for <>; Wed, 17 Jun 2020 06:59:08 -0700 (PDT)
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=b0y9uQV3kyT2L8MlmS4mkqEP/T+px+yFib4uE+Vqa0I=; b=coFkQn3UY4rb4Tw1buQW2C3M7pk8VBXP4aWnwoMLnyxE0pD6HvN3jrfKKT68A0oPY+ 2+EslUVuiGpSQuaEpzfnW9UP+gBJ3dS4uxyYVw0Ok0oEy4D6IFQOTjqqhjwz4qbZ4ofj uERtAWZKwircioJkUdwxT7P/rMlIQkJjFJwWB/4DrWVvEkL5hn9oEkgOK03rUEsWVx9N If2JFb9+8J9R2LKNp0ZeUFDHYBDsdASn2rrNn/HApl6UWVlgmxPG0yPv6u6eylnVP6zQ AMltirpuzvKVZJkbiQhyeBjb4M87coJsYbuaBKSzbLtYg49mxPvdmGQXiOyEttvkQuKk 4tzQ==
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=b0y9uQV3kyT2L8MlmS4mkqEP/T+px+yFib4uE+Vqa0I=; b=KCz4kbNkG0fhGpRLjKXuJmW2F3rNlPzL3rwQo/OqdhxSmW+8VuNqMd/W+T1kBywM4q lkBu/SMroI7L1LfdXn4T6iXxp7PA0Yrzbe3XYd2iyzB868yTFX8xIUcXXxqDH1SutaWF YUs0VIjt1TLzoTPB+7Ue0zImxOniNIOLKVbz49SrFdyrikr0kF6NhDegT3Fpg5OdfXRC g1x/WfEmVFyfH44KOQwbyCP7stnpe+Wraiwa8AoUqOM61/cpMbejmzkYvYt9jt2XoFrN PAOd3VOxgudDoxc5HEI7x3xuFolnlZ/YHPQy9T6MWrdNlMBaUDEaB1KFR97PXqnZgtx6 k41A==
X-Gm-Message-State: AOAM533K1PDsMw+Rt3FGZEye3atETrmzNGqFnVAj+wylj3krEvmzhVVK OvcAtoczuve4ElylnTXHD1GuhMzeUJQ=
X-Google-Smtp-Source: ABdhPJyVWijRS1VjLn0ayDYSS1RqVj2L4SWXvNdLjWgfK1dBbwynKKlP9J+Kh13cMExJZWnDxjooXg==
X-Received: by 2002:a2e:3c0f:: with SMTP id j15mr4427938lja.443.1592402346542; Wed, 17 Jun 2020 06:59:06 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id k22sm6030583lfg.69.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 06:59:05 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 17 Jun 2020 16:59:04 +0300
Cc: "Holland, Jake" <>, Ingemar Johansson S <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Wed, 17 Jun 2020 13:59:21 -0000

> On 17 Jun, 2020, at 4:20 pm, Ingemar Johansson S <> wrote:
> Given all the input sofar my impression is that It is difficult to say how serious issue 16 really is. 
> Surely there is a possibility that L4S flows can get an potentially unfair advantage over a congested node that is  RFC3168 capable (and ECN enabled). The question is here when things are deemed as unfair and when starvation is a fact, opinions differ. 
> Another question is to how large extent there will be legacy RFC3168 ECN capable (and ECN enabled ) bottlenecks that will "never" be updated or replaced. This question is currently difficult to answer. 

When questions such as these are "difficult to answer", the correct design choice is to assume pessimistically, unless and until the question can be answered more definitively.  Therefore, the L4S design must account for the possibility of RFC-3168 AQMs in the network, and actively avoid unfairness in that case.

> Yet another aspect is how successful it will be to implement RFC3168 bottleneck detection e.g. in TCP Prague, I am quite confident that these will not always be successful.

I think we can safely say that the detection mechanism currently in TCP Prague is not successful.  David Black also pointed out that this would always be a fragile mechanism, difficult to implement correctly, and thus likely to be implemented wrongly by other transports even if a workable version was somehow developed.

With these facts established, I do not see how L4S can proceed without changing the signalling mechanism it uses.  This is something we intuitively realised more than a year ago, when the SCE project was started, but now we have actual evidence to back up that intuition.

 - Jonathan Morton