Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

"Scharf, Michael" <> Sun, 21 July 2019 12:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3783B12017A for <>; Sun, 21 Jul 2019 05:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IO2IACIqjXvt for <>; Sun, 21 Jul 2019 05:30:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F23DA12012C for <>; Sun, 21 Jul 2019 05:30:41 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id CC5A125A12; Sun, 21 Jul 2019 14:30:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1563712239; bh=Rm8IKz6RPl7GDAbV2RKxHEE1tAninDIm6y4NNNyijgQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qPW/EeMWPgzbu2jkpW8LdnxxGXzKwxxeGfWcpt5xa4p08vgGAXq0RLUz1fQq0ziIA K6wcw3g4xtypSRf09Z2RPvNctKm61nw0uYHfXAEU2WKtFXfBXBC2v8HW7COCPOpZcE ayjHusR9+doLDz4NCd9Yo/b81kx5BBxSHiIZ0mdg=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B0TzXVVx3pCk; Sun, 21 Jul 2019 14:30:39 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sun, 21 Jul 2019 14:30:39 +0200 (CEST)
Received: from ([]) by ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 21 Jul 2019 14:30:38 +0200
From: "Scharf, Michael" <>
To: "Black, David" <>, Wesley Eddy <>, Dave Taht <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>
CC: "" <>, "" <>
Thread-Topic: [tsvwg] [Ecn-sane] Comments on L4S drafts
Date: Sun, 21 Jul 2019 12:30:38 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] 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: Sun, 21 Jul 2019 12:30:48 -0000

One comment, also with no hat on...

> -----Original Message-----
> From: tsvwg <> On Behalf Of Black, David
> Sent: Friday, July 19, 2019 10:06 PM
> To: Wesley Eddy <>om>; Dave Taht <>et>; De
> Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-
> Cc:;
> Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
> Two comments as an individual, not as a WG chair:
> > Mostly, they're things that an end-host algorithm needs
> > to do in order to behave nicely, that might be good things anyways
> > without regard to L4S in the network (coexist w/ Reno, avoid RTT bias,
> > work well w/ small RTT, be robust to reordering).  I am curious which
> > ones you think are too rigid ... maybe they can be loosened?
> [1] I have profoundly objected to L4S's RACK-like requirement (use time to
> detect loss, and in particular do not use 3DupACK) in public on multiple
> occasions

... and I have asked in public to remove the RACK requirement, too.

> because in reliable transport space, that forces use of TCP Prague,
> a protocol with which we have little to no deployment or operational
> experience.  Moreover, that requirement raises the bar for other protocols
> in a fashion that impacts endpoint firmware, and possibly hardware in some
> important (IMHO) environments where investing in those changes delivers
> little to no benefit.  The environments that I have in mind include a lot of data
> centers.  Process wise, I'm ok with addressing this objection via some sort of
> "controlled environment" escape clause text that makes this RACK-like
> requirement inapplicable in a "controlled environment" that does not need
> that behavior (e.g., where 3DupACK does not cause problems and is not
> expected to cause problems).

Also, note that the work on RACK is ongoing in TCPM. While there seems to be plenty of deployment expertise, it is perfectly possible that issues will be discovered in future. And we are pre-WGLC in TCPM, i.e., even the specification of RACK could still change.

In general, listing in one experiment requirements on the outcome of another ongoing experiment is a bad idea and should be avoided, IMHO. I have also mentioned this in the past and will not change my mind so easily. Historically, the IETF has good experience with bottom-up modular protocol mechanisms and running code instead of top-down architectures.