Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK"

"Scharf, Michael" <> Mon, 22 July 2019 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4A481201A1; Mon, 22 Jul 2019 01:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 rqEl8BVsvqWh; Mon, 22 Jul 2019 01:51:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E749120191; Mon, 22 Jul 2019 01:51:46 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id D1FC025A12; Mon, 22 Jul 2019 10:51:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1563785504; bh=AAMUf5lxs5R5dYM86TaP90xCm++ev5TuMXxyaPROAVI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qa26ufMVIyMZxqkoXzcJ4R4av/alLXdtjKnTYVMvM3G+aEujb6oxMYrOrbsuubE6J jVVBA4T00GtKwYCxP88yA8BVhZwVR9PnOaUkoHHTrK2chwmk9SLeWKszTGpQsdKGQb X0LPqL0p9jHsDsaXUYEu+V/E0JUxPC2uBsXY8oLc=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3fp52KNFnsPY; Mon, 22 Jul 2019 10:51:42 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 22 Jul 2019 10:51:42 +0200 (CEST)
Received: from ([]) by ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Mon, 22 Jul 2019 10:51:42 +0200
From: "Scharf, Michael" <>
To: Bob Briscoe <>, Praveen Balasubramanian <>, "" <>
CC: "" <>
Thread-Topic: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK"
Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04QAAaGWYAAD7CAQAAA6LeAAAIdXND///yrgIAABP8AgABrZoD//40q8IGPmtoA//9tY5A=
Date: Mon, 22 Jul 2019 08:51:42 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3C1119rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jul 2019 08:51:49 -0000

[Sorry for stripping the original text, but mailman complains about >100KB size]

Hi Bob,

To me, none of these issues are specific to L4S. They are not even specific to use of ECN or congestion control. To me, it is a valid but orthogonal problem.

As I result, with TCPM chair hat off, I continue to disagree that this belongs into the L4S experiment.

Specifically, I disagree that this shall be bundled with an ECN codepoint allocation. If L4S used another identifier, e.g., a protocol identifier different to TCP, I would maybe be less concerned, but my point that it sounds entirely orthogonal would still apply.

As an individual contributor, who does not own running code (i.e., I have not much to say in the IETF at the end of the day), I believe that the MUST requirement for “detect loss by counting in time-based units” must either be removed or, maybe as a compromise, converted into a SHOULD.

I do agree that TCPM needs to think about this, probably together with TSVWG, but I fail to see the need of urgency. And, yes, this may result in TCPM standards track standardization (e.g., a RACK specification as PS). But if TCPM sorts this out, we need to solve the issue for TCP as a whole and not for one experiment only.

BTW, your comment on the delay of a PS specification misses the key point. Formally, TCPM can publish a PS RFC within few months. Any delay on top of this comes from the comprehensive validation and feedback from implementers that is needed on standards track. If there is industry consensus on doing something in that space, and corresponding energy, TCPM will not be the bottleneck, IMHO.

Note that it is perfectly fine if I finally end up in the rough part of the consensus.