Re: [tsvwg] L4S vs SCE

Pete Heist <> Thu, 21 November 2019 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66C571208CF for <>; Thu, 21 Nov 2019 04:58:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 4tDZQNT7IM3W for <>; Thu, 21 Nov 2019 04:58:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7359A120043 for <>; Thu, 21 Nov 2019 04:58:10 -0800 (PST)
Received: by with SMTP id b10so1568774pgd.4 for <>; Thu, 21 Nov 2019 04:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pBixEfCICizt36Qj7uA64eE9zxJNEbYhQQOkqUn+mE=; b=gE0i6JZfYdBzrxqqN4vf95ldPkTr+UmBIab8dsbqWJTugw0Q8V0hwnyUlgMV1cD0LU xnpnhwQFkSpaX9nfQrQUKjJbtswv2+sH0PKB13QtP59/AVaXpGWuoVTVDvQaJU+tcU7/ WQST1PkUrzCs2yMB13QDb74RVtkFv1ODwGlE0PD3ONLu2jX4Zv2EOSuzPoCBsFwppjIV eZyzq+x+B0+sRM2kR2UBz1xD/fw8q6inDoySbpKm49bZ6JVHkT4iXYPFk75pvUQHl4MB Ov9ty/qp8L+s/TH3Pk451vpRI26v9PN2zo8kqQicuiFTMvU/Jc/FmA3461DsJlCcHsqu 5ntA==
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=7pBixEfCICizt36Qj7uA64eE9zxJNEbYhQQOkqUn+mE=; b=rlq5lgzBuk+iF2RrqcdFkUy3auScqUG8evY6EJvPmCOquPJL9L8gMxJ4jx3uceT1jg LDbFRmzLvVqOGOQezfXqQxaxTkAoGYKTbrGkwIr4WZLg8ZEgt4SUAjLPio3vjoHCUVlW 7PtLFcaRRBvzCyLh3JoeYDDv3q4GG8FAb/4Df1BOAVjjXoGDDTWSeGlyThie+sXHtvj1 wGQ9qjJYfSln+jorcaWmrhz5ht6smwkp0aR1ehDIhH9lPD08xw+470iPYXmZoiZJovwn RuLQ+SyF0y0QOmfBvhfQ+9NJsUfX7x/xgob/cReWBl5Zx694dSeuTVpGwfnEg1hkAvS7 yTNg==
X-Gm-Message-State: APjAAAUY7pRM6i7ANC9bsjL1LupxoqkDeNTqrzeFC3XSBcBzQnGaQi4T vr2UieWaRRo8LWildHExg+QOdVmlgnA=
X-Google-Smtp-Source: APXvYqw0t46MLXIdmPLzRusaIfb1fpFZz9+yoatkNqH3YZxLOxzAYuK69mdBhcZn/tyGqpUg3oHyLQ==
X-Received: by 2002:a62:e105:: with SMTP id q5mr10717321pfh.105.1574341089860; Thu, 21 Nov 2019 04:58:09 -0800 (PST)
Received: from yoda.lan ([]) by with ESMTPSA id y1sm3568832pfq.138.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 04:58:09 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <>
In-Reply-To: <>
Date: Thu, 21 Nov 2019 20:58:05 +0800
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Greg White <>
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: Thu, 21 Nov 2019 12:58:12 -0000

> On Nov 21, 2019, at 7:14 AM, Greg White <> wrote:
> 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.  I don't believe that the IETF should use the last IP codepoint for a signaling mechanism that can *only* work in FQ.

The thoughts are appreciated. What I think needs to be clarified is that SCE doesn’t necessarily require full FQ using the traditional many queues approach. It only requires some level of help from the network, when fairness between SCE and non-SCE flows is required. Options include:

- Changing the SCE marking ramp, trading off some of the advantages of SCE for improved fairness. This was first described at IETF 105 in Montreal.
- Using CNQ, which is implemented but we didn’t have time to present today. That provides a minimal level of improved fairness that can actually favor SCE flows early in their lifetime.
- Using LFQ, which like CNQ, is in draft form with a crude discrete time simulation, but doesn’t yet have an implementation. This provides closer to full FQ but with a lighter weight implementation.

This is still an active area of research with many options available to us, and we feel it’s a tractable problem. We just want to make clear that “SCE requires FQ” isn’t very accurate, and needs more clarification as to the current and future options available.