Re: [tsvwg] Comments on L4S drafts

"Holland, Jake" <> Fri, 14 June 2019 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17B52120742 for <>; Fri, 14 Jun 2019 11:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 bg-a1-OvccJa for <>; Fri, 14 Jun 2019 11:28:27 -0700 (PDT)
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 0858512072C for <>; Fri, 14 Jun 2019 11:28:26 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x5EIGxlj011251; Fri, 14 Jun 2019 19:27:41 +0100
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=3smOb8HcTR1UoNk1v6afcsd4s+gtkLMl6ZkmJBTC2/8=; b=TlY5RwAFPbhwYnpblPUgGn/osn2nqrDS4XzBpdiy54YRjycBX0YoHTF8D7+N/fn1lENp o6onHfIItBwsfM6SvNPstrDbB/erlN6gNDa6477uOqZOOXubGqT4qrSzWuS1FH0rbqCc rQ0VwlQO6mO0UehMI/81+rmKA72TYkP6R8CTZ1iiLdIhnd6gW3MlABY56DLJKKKqtdLU IHd0361bVNlKxQKVDrZXT6V0limhl4YGdxtH+7VKUSNHKxZgCQtDnCLUSLfLsoQCYmFH i3ucgfN72uL50L2sJ0fxHtH3jha9KG71m88pUal5aTXB217zvbX+cpHeBp82OnJEFJut jA==
Received: from prod-mail-ppoint2 ( [] (may be forged)) by with ESMTP id 2t3xnabefg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Jun 2019 19:27:40 +0100
Received: from pps.filterd ( []) by ( with SMTP id x5EIJ1Qj015621; Fri, 14 Jun 2019 14:27:39 -0400
Received: from ([]) by with ESMTP id 2t08bxu7ry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 14 Jun 2019 14:27:39 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 14 Jun 2019 13:27:37 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.004; Fri, 14 Jun 2019 13:27:37 -0500
From: "Holland, Jake" <>
To: Ingemar Johansson S <>, Bob Briscoe <>
CC: "" <>
Thread-Topic: [tsvwg] Comments on L4S drafts
Thread-Index: AdUeK8SLhgyjMeS8RyC1czIhZ3l0vwEok9eA
Date: Fri, 14 Jun 2019 18:27:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1a.0.190609
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-06-14_07:, , 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=821 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906140145
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-14_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=842 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906140145
Archived-At: <>
Subject: Re: [tsvwg] Comments on L4S drafts
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: Fri, 14 Jun 2019 18:28:36 -0000

Hi Ingemar,
(bcc: ecn-sane, to keep them apprised on the discussion).

Thanks for chiming in on this.  A few comments inline:

On 2019-06-08, 12:46, "Ingemar Johansson S" <> wrote:
> Up until now it has been quite a challenge to make ECN happen, I believe
> that part of the reason has been that ECN is not judged to give a large
> enough gain. 

Could you elaborate on this point?  

I haven't been sure how to think about the claims in the l4s drafts that
operators will deploy it rapidly because of performance.

Based on past analyses (e.g. the classic ECN rollout case study in RFC
8170 [1]), I thought network operators had a very "safety first" outlook on
these things, and that rapid deployment for performance benefits seemed
like wishful thinking.

But I'd be interested to know more about why that view might be mistaken.

> Besides this, L4S has the nice
> property that it has potential to allow for faster rate increase when link
> capacity increases.

I think section 3.4 of RFC 8257 says the rate increase would be the
   A DCTCP sender grows its congestion window in the same way as
   conventional TCP.

I guess this is referring to the paced chirping for rapid growth idea
presented last time?

I'm a little unclear on how safe this can be made, but I agree it seems
useful if it can work well.

Do you think the L4S benefits will still be sufficient if this point
about faster growth doesn't hold up (and/or could be replicated regardless
of L4S), or is it critical to providing sufficient benefit in 3GPP?

(Note: I'm not taking a position on this point, just asking about how
much this point matters to the 3GPP support, as you see it.)

> I see many applications that can benefit greatly from L4S, besides AR/VR,
> there is also an increased interest in the deployment of remote control
> capabilities for vehicles such as cars, trucks and drones, all of which
> require low latency video streaming.

Remote control over the internet instead of a direct radio link is an
interesting use case.  Do you happen to know the research about delay
parameters that make the difference between viable or not viable for

This touches on one of the reasons I've been skeptical that the benefits
will drive a rapid deployment--in most of the use cases I've come up with,
it seems like reducing delay from ~200-500ms down to ~15-30ms (as seems
achievable even for single queue with classic AQM) would give almost
all the same benefits as reducing from ~15-30ms down to 1ms.

Of course, there's a difference in that last 14-29ms, but for instance
for gaming reaction time it's well under the thresholds that make a
difference for humans (the low end of which is at 45ms, according to
[2]), so it seems like the value in that market would be captured by
classic ECN, and therefore since classic ECN deployment hasn't caught
on yet, I had to conclude that the performance gains to enable that
market aren't sufficient to drive wide adoption.

So I'm curious to know more about the use cases that get over that
hump from an operator's point of view, and what you've seen that leads
you to believe the additional gains of L4S from will make the difference
on those use cases where classic ECN wasn't adequate.

> My bottomline is that I believe L4S provides with a clear benefit that is
> large enough to be more widely accepted in 3GPP. SCE is as I see it more
> like something that is just a minor enhancement to ECN and is therefore much
> harder to sell in to 3GPP.   

Thanks, this is good to know.

To me one benefit of SCE over L4S is that it seems safer to avoid
relying on an ambiguous signal (namely a CE that we don't know which
kind of AQM set it) in a control system, while still providing high-
fidelity info about the network device congestion, where available.

I agree that it's not completely clear exactly how the congestion
controllers can capitalize on that info, but to me it still seems worth

So although I'll support L4S if it really covers all the safety issues
and performs better, I'd be more comfortable with the signaling if
there's a way to make SCE do the same job, especially if the endpoint
implementation is simpler to get robustly deployed.

So really, I'm hoping for a bakeoff to decide this, because one of my
concerns is that L4S still doesn't have an implementation that does
all the things the drafts say are needed for safety on the internet,
even though the initial proof of concept demoing the performance
gains was presented 7 years ago.  It's good that it's getting closer,
but the long implementation cycle (which still doesn't have all the
features required by the drafts) is a concern for me from the
"running code" point of view.

On this point of view, it's possible that a parallel track might get
further faster, especially if it doesn't need the same special cases
to be safe, which is part of why I've been tentatively supportive.

And although I can see how the queue classification is a major issue
that could make the difference, especially with the very promising
dualq proposal, it also seems true that in addition to CPEs, there are
promising avenues for carrier-scale FQ systems (e.g [3], [4]) that could
solve that.  It makes me think that even if SCE only gets low-latency
with FQ and otherwise causes no harm, it's not clear it'll be a slower
path to ubiquitous deployment (and by the way, this approach also would
handle the opt-in access control problem).

Of course, this will presumably collapse to one answer at some point,
but I'll argue that it's worthwhile to give a good look to the alternate

Anyway, thanks for the comments, I think it's good to see more
discussion on this.

Best regards,

[1] Appendix A.1 RFC 8170
[2] says 45ms