Re: [tsvwg] L4S vs SCE

"Holland, Jake" <> Wed, 20 November 2019 03:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85E82120AC6; Tue, 19 Nov 2019 19:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 IulcGZtkJa_8; Tue, 19 Nov 2019 19:48:22 -0800 (PST)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 730571209C4; Tue, 19 Nov 2019 19:48:22 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id xAK3gY2D023680; Wed, 20 Nov 2019 03:47:15 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=rTvOMMMJsg2tdU21X+nENyimW/OOpyVYed+PR/T//4Q=; b=W/xFHYKbGCgKvqVi6Q7uuX1MVe/QIsrqjKeU/FxZP49yga7I8vOHuqXOcJnxB2/6/ZMq L/S4I/u8hjmsOX6DgG76O7to7WXL7Lryr6c8WbP281PXFf4+PlHQs7OBBatBDMkayJQz J7XdFKTaJNt1H/ijiZ7lz4W7uOPA+3QAl4la8ZXy6/mkDyyOYc3/YGmocSv6lpztrDTm /QYwPpnTQg0LjoJ+V5TD3uqANw7F9+kFrKelvLioTwhxAxq07tIXH3BFPzcGU29uUR+l Ejv6R8OfmRVbxH4MSL2DoLWSAJ7uGikMUeMto+s8laSnfTX1gWHksS0YbwbWn9gqmmyA FA==
Received: from prod-mail-ppoint7 ( [] (may be forged)) by with ESMTP id 2wafutqvc7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 03:47:15 +0000
Received: from pps.filterd ( []) by ( with SMTP id xAK3WIFp009881; Tue, 19 Nov 2019 22:47:14 -0500
Received: from ([]) by with ESMTP id 2wadb472y7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 22:47:08 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 19:46:37 -0800
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Tue, 19 Nov 2019 21:46:37 -0600
From: "Holland, Jake" <>
To: Wesley Eddy <>, Ingemar Johansson S <>, "" <>
CC: "" <>, "De Schepper, Koen (Koen)" <>, "" <>
Thread-Topic: [tsvwg] L4S vs SCE
Thread-Index: AdWe0nrRkrzku9jhQamw6kS06HsgqgAXfuGAAAT4HQA=
Date: Wed, 20 Nov 2019 03:46:36 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200030
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_08:2019-11-15,2019-11-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200031
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 03:48:27 -0000

From: Wesley Eddy <>
Date: 2019-11-20 at 01:24
> • concern that there can only be one of L4S or SCE happening 

There was a side discussion about this I think is worth mentioning:

It might not be hard to consider the consequences of mis-classification
that could occur in the "both experiments" scenario.  If the concern
about co-existence is primarily technical, at first glance it doesn't
seem too dire:

(PS: I acknowledge that there may be legitimate non-technical concerns
with running both experiments simultaneously, but have nothing else
to add to that discussion right now--if your concerns are only non-
technical feel free to skip this section.)

1. If a SCE connection runs across a chained SCE-L4S link,
then there's a risk that the SCE node would mark ECT(1), which
would then be mis-classified as an L4S packet by the L4S box
box.  This makes the marked packet likely to be re-ordered,
plus gives it a higher probability of being marked CE, which
would cause a higher backoff than necessary for the SCE sender.

This seems like not a disaster, since at least it fails safely
with a MD backoff.  The cost is some performance penalty to
SCE, but only when both aqms were lightly congested, and the
sender responds as if at least one was heavily congested.

(In the reverse direction, ECT(0) would already be classic traffic
for the L4S queue, so there's no impact.)

2. If an L4S connection runs across a chained SCE-L4S link, the
ECT(1) packets from the L4S sender would be mis-classified in the
SCE node as already-marked SCE by upstream.

If I understand the SCE versions of CNQ and CAKE correctly, this
would have no impact--the ECT(1) packets would be marked CE when
the congestion level is high enough (and won't get any SCE marks
since they already appear to be SCE-marked), but this is no
different from the behavior of any other 3168 aqm.

Are there other scenarios that need consideration?

As far as technical concerns go, these 2 situations don't seem
like a high barrier to running both experiments simultaneously, but
of course I'd welcome comments about other considerations this
brief analysis misses.

> • maybe lack of understanding about how and where people are hoping to use/deploy L4S?  (like as an operator, what else would be there that mitigates some of the concerns people have, and that supports gathering experimental results, etc)

+1, these suggestions sound very helpful to me.  Mitigation strategies,
expectations, end conditions for the experiments, monitoring and
evaluation plans, any restrictions on scope of intended deployment;
all these would be valuable additions to the docs IMO, and it would
strongly mitigate my safety concerns if there were reasonable guard
rails described.

> • entangled evaluation of L4S with TCP Prague (I see this badly in the threads ... From what I can tell, the public test Prague code doesn't yet meet all the Prague requirements in the L4S draft, and that's caused some explosion of emails.) 

Yes, sorry about my contributions to this problem.  I wasn't sure
how to make the point about the level of confidence we can have in
the safety properties of an L4S rollout (and how it relates to the
likely impact of wg adoption decisions on external SDOs) without
bringing up the examples from the TCP Prague testing.

Maybe it would have been better just to point out that we don't yet
know whether the safety requirements of L4S can be achieved, since
we haven't yet seen running code that meets them, rather than
introducing confusion by pointing to example tests of something
that doesn't yet try to implement those requirements.

The point is well-taken, both from you and from Greg's earlier
message to that effect, and I'll try to be more clear on this
distinction in the future.

Best regards,