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

"Scharf, Michael" <> Thu, 08 November 2018 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E255712F295; Thu, 8 Nov 2018 08:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 sejjj1LGmr3c; Thu, 8 Nov 2018 08:35:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CAD0128BCC; Thu, 8 Nov 2018 08:35:04 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id B3FA925A17; Thu, 8 Nov 2018 17:35:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1541694902; bh=15lO1jkTSb1SZkdL0GEv20VeZFAISuw7KEIxEWuXzmM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WWi0u/w1ZtYwTxDoKphpzdEvd9wIrU3p6q6Bag4S1W7zlIinpnofGOnPUHwknmoXN 13Uuv8qr2Ax6ldK3vjiT3KuTh4nYcksY38DZPsrSXa2zCw5WwC7PdKPIfvObD8f/qT E6MQE2ZH4D10yYzZGSp3GBcUk9GDmx9MLa2AJ4w8=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ItRtp1Dmlm3i; Thu, 8 Nov 2018 17:35:02 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 8 Nov 2018 17:35:02 +0100 (CET)
Received: from ([]) by ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Thu, 8 Nov 2018 17:35:02 +0100
From: "Scharf, Michael" <>
To: Bob Briscoe <>, "" <>
CC: "" <>
Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK"
Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqA=
Date: Thu, 8 Nov 2018 16:35:01 +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_6EC6417807D9754DA64F3087E2E2E03E2D15201Arznt8114rzntrzd_"
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: Thu, 08 Nov 2018 16:35:08 -0000

Inline [ms]

From: Bob Briscoe []
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael;
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"


This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  *   L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  *   The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

  *   In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  *   When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.
[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.
The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.
[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…
[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.
Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).
[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":

As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.

So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?


(who recently had to review draft-ietf-detnet-architecture)



Bob Briscoe