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

Bob Briscoe <> Thu, 08 November 2018 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBDE0123FFD; Thu, 8 Nov 2018 03:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_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 f4fjYUbIvt02; Thu, 8 Nov 2018 03:55:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BFDD12896A; Thu, 8 Nov 2018 03:55:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EC3iUSN2yCGc+kEqvmDXNIh4i9sQVVPOB+P5rv3kt1E=; b=IBKNNafgs5y+BfxifkRZixnzQ pdDy4V+8+pctN3NKGKSOaVYEt1JGbgdsDMmch9RKlfJF6pS42iaGQponGNwZEmXBsOZmRsh3n7h3F NNkRHiex5bOwZ0S3Ni6DBAUC3LNEHSAlP/44lgrxWj/v2/d0RCocAfWwhhJ4VTPaXf3nIbfE5A8/7 kKdSspUq2L4WvajuPEIUwCFLCU0ZKvBomGCCGaPXUmNKG17QSJSCpiG7twdEuB1/xzKdBw1++pyAg WMFH/tIGLXZdDaD4ISNLU8I71BRdjI8zC107XKjcna/vydg++2rRzSmt2l8RzSIrONoWy4LHNIjdx 8w+jB3Uvw==;
Received: from ([]:41494) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <>) id 1gKiuM-0003kc-Kh; Thu, 08 Nov 2018 11:55:34 +0000
To: "Scharf, Michael" <>, "" <>
Cc: "" <>
References: <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 8 Nov 2018 11:55:31 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------93F7985647850F4F3DF81E38"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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 11:55:39 -0000


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.

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.

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).


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?
> Michael
> (who recently had to review draft-ietf-detnet-architecture)

Bob Briscoe