Re: [tsvwg] L4S vs SCE

Jonathan Morton <> Thu, 21 November 2019 08:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55E20120822; Thu, 21 Nov 2019 00:05:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ndy58td37GbF; Thu, 21 Nov 2019 00:05:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 504E6120048; Thu, 21 Nov 2019 00:05:43 -0800 (PST)
Received: by with SMTP id b188so2314936qkg.1; Thu, 21 Nov 2019 00:05:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2D9pk9BepdGDiAoYxRdf3ockqYNU/MamhRIfCtxJLNg=; b=sAZDFQeIYJd3WzKgN1ljxSrvmnTNADist+0zZDH2bYzdO0yTBhLlBByKlASZ9X/156 6t+HxQBoAc9boX4StVUKYxkfv4KyD95VjWwWA00q6L+wJyGY8H1Yxsg/CrhihkSshEAV 4n5SCHJobXqv7PWtU7EnL4qEYbL6ECGBBxE9tIbBfP0s5Vea0h1RU7ftG9qAyye/Rdj4 eZiu/zcC81MHtFAXA/ovyAQ20np7SidIOAN2y19a+lYvDKdAyiLQPrACNeHHq4nUs0pD AVBXnGrPAfSEKJyZUC3CjgmqYwnHMm1x3fLezcu/A/IeUCCdiAb9EDybLnXSakAAo40N dcRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2D9pk9BepdGDiAoYxRdf3ockqYNU/MamhRIfCtxJLNg=; b=OdDweN8vsc6u2X3SQHJaRT7qNIh2b8HLsetbX3ufzWZUyQ6I2+rCXm6t+KeOBQBlkf rVqVNK4WyyMyweISmUKhVWiS3NxI9Yz3+LHSrajgBQDPR8XIOhhxrWzdx4o4FDsqZMnU a7Qhi0oCTO+0Th1xV83h1BzUa5/ZKzPKigSHBDRYwLf1s8YGehKys4v1dbRIzgPdtyIf bCTxAI2njyMOPHYAl+SmyFBjIAK1A2GRhpDHVp95J8nr1Hwe42NLxOedGpDhlXdSZB6L FQ6UvyiRSYWc9Q4q7HrqyitaqbM4bkH2ITkpyYr032cOGQhCF2kKuOh9BIlX0rG9jWfv y6kA==
X-Gm-Message-State: APjAAAWmSm2RIDWRDzACt5We8e1I0eX3Tkmzp0g4M/qSA0OVwlkkZclY u8doPkS8l3zJWw3o2goYF5pGFN+sm9tPCE4nQSo=
X-Google-Smtp-Source: APXvYqx6ZaeQgUUGLCdpPDCOw4opFNuLyWNKXnV0wLqdNTEJ3xfEjpD28GZ0g512C3cJegG2MYHT/GbMNGeQrj9b0As=
X-Received: by 2002:a05:620a:131a:: with SMTP id o26mr1572982qkj.160.1574323542428; Thu, 21 Nov 2019 00:05:42 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a0c:e48b:0:0:0:0:0 with HTTP; Thu, 21 Nov 2019 00:05:41 -0800 (PST)
Received: by 2002:a0c:e48b:0:0:0:0:0 with HTTP; Thu, 21 Nov 2019 00:05:41 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Jonathan Morton <>
Date: Thu, 21 Nov 2019 10:05:41 +0200
Message-ID: <>
To: Sebastian Moeller <>
Cc: "" <>, "Scheffenegger, Richard" <>, Pete Heist <>, Roland Bless <>,, Greg White <>
Content-Type: multipart/alternative; boundary="0000000000008210020597d6c3d0"
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: Thu, 21 Nov 2019 08:05:44 -0000

>>Where I think SCE fails is that it is not available to any link that
doesn't implement FQ, whether that is by choice or by necessity.
>         [SM] SCE is a marking strategy pure and simple. I see no
insurmountable obstacle in combining the backward compatible SCE marking
strategy with a better classifier to give L4S queueing to selected traffic.

I prefer to describe SCE as a signalling mechanism, one which can support a
variety of marking strategies (e.g. threshold, RED, Codel) and response

That is the fundamental difference here, and I think that L4S could
reasonably switch to SCE signalling with essentially all of its advertised
goals intact.  That would be a robust way to close several of the
outstanding issues in the tracker.

I should also note that whenever there is unfairness between SCE and
non-SCE flows, it it's in favour of the non-SCE flows.  This means SCE is
safe to deploy even in a single queue; it just might not perform well.  The
reverse is true of L4S, which is why it needs protection for safe
deployment unless and until the RFC-3168 detection heuristic is shown to
work robustly.

- Jonathan Morton