Re: [tsvwg] L4S vs SCE

Jonathan Morton <> Wed, 20 November 2019 04:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B62571201E0; Tue, 19 Nov 2019 20:23:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZmegmOehnFsR; Tue, 19 Nov 2019 20:23:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58976120143; Tue, 19 Nov 2019 20:23:58 -0800 (PST)
Received: by with SMTP id ep1so3585754pjb.7; Tue, 19 Nov 2019 20:23:58 -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=2d+OaQHF+tDLgDK4vLuJ3qmH5CoJJitnumoo/Stsmrs=; b=DW0HF6N690YX3SfI4YWGytWpf6V+pw3A5wVB0l9l9ot3DhaplXXAFjuDoLFL9vGtZb L/9U5dtR8KL/klPfWd4xQPkhuDqD7OyzvwPNAtVnSGgzfjwKefpqinYxAv5kX4v6wRB/ 2H0Xd3f4oz6omaI+mGZUn7LdIj7lHiDcSvoQUf+ljA4LvbYqdoL1nZYR38vtotRgXvUx Cd7Wb41cLBXW7Z8KaMT60+bJ4zn4eDWET5j5JWt+8TG5L3k/vs+/FaOamdkfCqxOjJEV 724rc8bnGuIBBa46HeLYChPofKeHvB6XiITKBnCUIagDujYI3d0krHDjTSCOH0CgMShB QL0w==
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=2d+OaQHF+tDLgDK4vLuJ3qmH5CoJJitnumoo/Stsmrs=; b=PQxGL18lykKC7lEy3xrzaSxfdLQFrSdt3IfW29RwKh9olJf1fK4zPSuJrV3kvkcKPn 3YcQLk4TUN8v/7mEBI8ajrIp5SwUl/RD3Z7Ot/7zeU/YQ0GAXyjZt4Fy+HsynL1SPWmh 0DnCcGFHNtayacB/PMBQ7Iqaku4Pgx+yC1zDAfQLyUdMIIpGfE0KcazUJqe+pKNNAM53 BNi0Zq3C7nD3nDdWYY+jFkHGKYQy2bs9uOW3IxLinBSwSlkuzOHVAU4K7HjHVoLWf4F2 SfbCy8b/yx13Oj7wee3DR4n8UqfVP4RrkLuJ2Q931pFP3UpCxkgp5rRTZCUdsXNk0pA2 fEuw==
X-Gm-Message-State: APjAAAWVta8O+yfqDrdmHFiYv6x/me+nBdMnDpUKGmLjn2tLSMxxNDMj Y77W4abUGm8aSDUhih2SL84=
X-Google-Smtp-Source: APXvYqzDF9bO2oeiN2jXZY27ttBxglhzeKvhkP+UjLT4pHPMq7keCBHQgstQ8qZCZSwog3GW6C9r1A==
X-Received: by 2002:a17:902:ff06:: with SMTP id f6mr828060plj.65.1574223837575; Tue, 19 Nov 2019 20:23:57 -0800 (PST)
Received: from jonathartonsmbp.lan ([]) by with ESMTPSA id j20sm26540401pff.182.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 20:23:57 -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: Wed, 20 Nov 2019 12:23:54 +0800
Cc: "Holland, Jake" <>, "" <>, Ingemar Johansson S <>, "" <>, "De Schepper, Koen (Koen)" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: G Fairhurst <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] L4S vs SCE
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, 20 Nov 2019 04:24:00 -0000

> On 20 Nov, 2019, at 12:03 pm, G Fairhurst <> wrote:
> Would an SCE router likely preserve or change the queueing of ECT(1) L4S traffic? - is this behvaiour different to any existing ECN-marking router?

SCE middleboxes don't queue or handle ECN(1)-marked or CE-marked traffic any differently from ECT(0) traffic.  The a-priori ECT(1) marking merely removes the option of applying an SCE mark.

CE marking on L4S traffic will be as per RFC-3168; it is already incumbent upon L4S to cope with that.

> And would SCE traffic arriving at the L4S queue meet L4S expectations in terms of responsiveness?

Yes, since the MD response to CE is actually more severe/conservative than what L4S expects.

> Have we thoughts on what would happen with SCE?

The current Linux implementations all have SCE functionality gated behind a non-default setting, so users have to explicitly turn it on.  I think this should make it relatively easy to clean up an abortive deployment, should it be required.  Specifically:

- The sch_cake, sch_fq_codel, and sch_cnq_cobalt qdiscs each require a non-default tc parameter to enable SCE marking.  Without it, they purely support RFC-3168 and will not increase the incidence of ECT(1) codepoints.

- Receiver echoing of SCE marks into the ESCE flag is controlled by the net.ipv4.tcp_sce sysctl.  This behaviour differs from that of Nonce Sum receivers but involves the same codepoint and flag bit.

- Sender responses to the ESCE flag are enabled by explicitly selecting one of the modified TCP algorithms.  If these are selected but no ESCE flags appear, they behave like ordinary RFC-3168 compliant Reno or CUBIC implementations.

Is that sufficient, or does a more detailed analysis need to be organised?

 - Jonathan Morton