Re: [tsvwg] L4S and the RACK requirement Mon, 18 February 2019 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F272D130EF2 for <>; Mon, 18 Feb 2019 04:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kVk5oWSXKI07 for <>; Mon, 18 Feb 2019 04:36:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00ADE127AC2 for <>; Mon, 18 Feb 2019 04:36:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1550493371; bh=B81Ycu2GFQmNjuRdx6HcsJeUJrDp3TXMGu1rG18Pd90=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=aEPNTELLjE+OcgIrMSd1ZASIFmNLyMdQ0wphtS310rk/vwODiLarXCiQx3dg2F7jnZUwRYP4hG5wb//kHr3TuDG50qJQc5mZJzy7cbgprnPyFegOtmyG+jknn47QC1hP5aSgtB1A36PT/QLBuJtf4H1EYnYmi1tBm7yKQBS0feafTkhItxdFVqke7198eLTqkV09x7AeJegF/ZxpAC8vlOmIdsg5zKHr4NRsV2AIJHt+bGC0twTyNHQE8Q1b6TEoAo/j8RwUg4SH9q07PTSiKeCr+pEx8e6BMzo70nKilJmIqi0NTDi938IGwg93B1Z29Ij55AD0uhxxtxK7NWzpeA==
X-YMail-OSG: 8Gea1EsVM1mndHq_J.gnCpKcfzhQACpvmymHDmZk9xjSKeaXZLPUA4A4qlvc6uv BvxI3OfRinRa8fDnd8LEhJ6crOhiK9AHVnDYClBbZ5IPw00nSVRO13hlBa7ECn13wPQdIhv9udec lHnCvtB.8f.u3MCbKimSEWsmYkkCCfsyKRXRCYlB8tW1KOosmZvcaC1gY88kH3a6RphZAVf2Fo0T QAFapjgq2698WsV_VQV3z5ONEP4UjnlWwvuX1tGLAqy4x94mWUZ8crMPUdYhNxL13dunX2LReba. AzUBAyhRiz57V9JSk7XvzWtUmzZf4WN7EA3Npqhi2VJzwkQMUiKpOkGXLa8NUtyl2mYU26GVpBhf vtJ9WqxUKxJZbN4vISr6hJeaC53WguSQWKounAqZDQFqZowCk4YBX0QPRiHx.SpoBePprTdf2Llg NyGp.wF0it.X9fRF_Cy5Z.sH0w9tJ9NNnBgZoV_vK.ph3MnJUbZJVfMWUwIuthpwerr4OOd02OSp w2RD.8YehVOc0g7kbGEpPaPiVH_e7jieXHaAlIc7AurUFelFIYc5jMPJ.TA3BYRvPqJutbjeV9QG .IV.XpgEfMlb1tfwHEWXudtwHoseijW0cL0Fm.q.sf49zyG_Le1kbgy22iRZ1WuqkhM5FfQm86S2 gBIwHfcgIojXJrzLGPItC8jJvQFpSVjKL8VY7zW7BpqqsOmeG_bLaFcCGEuIq54AqCcgC_Hd0li1 GxnceeblZLnoTtoWlmQGPV3oNJ8TzVo8hpA4f4713gqbZIOWAdbD7GHzL.7h34irj.td5EQr5Owt rCHLHOnmwvhhgBrLw0WQNLyJUji3QsxaHVWkazZPdY1XmN8cM5QggMLKMpkyOey9obc4nqJdBAsc O5R8PVsFOV1JZUe187gNqUEqPJQ4JRjBlKfObCoM8nen0DxqL7Lje9jw5u75WBrh.gdgrrUUOd.n DdsKP0Q8yzBUjUGLuowwLxWIVjIa9ZuE.8sIK2RXE8aRiAsNodu5DcV5mHPatrkaWkUblfr.4hCP Ge1pHBKHAotODTTbEkxhhT4kKwNt3Wt9ciIIPJyknY8AJWjEC4urUZluqg8VopLxWXw--
Received: from by with HTTP; Mon, 18 Feb 2019 12:36:11 +0000
Date: Mon, 18 Feb 2019 12:36:08 +0000 (UTC)
To: Wesley Eddy <>, Tsvwg IETF List <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1534459_472111610.1550493368195"
X-Mailer: WebService/1.1.13123 YahooMailIosMobile Raven/44161 CFNetwork/811.5.4 Darwin/16.7.0
Archived-At: <>
Subject: Re: [tsvwg] L4S and the RACK requirement
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: Mon, 18 Feb 2019 12:36:17 -0000

Am I the only person who remembers Savage attacks from ack splitting and packet counting? 
there's the support for the MUST NOT, at least. I's not the lack of scale that is the major issue there, it's being open to abuse. ack counting didn't work...
Time is a tricky thing to handle with vatying scale, as delay-tolerant networking has shown.


On Wednesday, February 13, 2019, 5:00 am, Wesley Eddy <> wrote:

In discussion among the TSVWG chairs, we are concerned about lack of 
consensus on the requirement currently in L4S ID draft ( ) regarding 
the need for RACK-like behavior in a transport that uses the L4S queue.

The statement in the draft is:

     A scalable congestion control MUST detect loss by counting in units 
of time, which is scalable, and MUST NOT count in units of packets (as 
in the 3 DupACK rule of traditional TCP), which is not scalable (see 
Appendix A.1.7 for rationale).

By saying this, it seems to rule out DCTCP and some other existing code 
that might be used with L4S (and DCTCP discussed in the draft as an 
example scalable transport, even though it violates this rule (?)).  
This seems like a bit of a problem for making L4S usable.  I guess maybe 
TCP Prague code fixes this, but isn't as widely available yet?

The discussion in the appendix is good at explaining what I think the 
real goal is here, which is to enable major reduction in latency from 
link-layer (or other underlying transport network) re-ordering buffers.  
We want that in order to meet the low latency goals, which makes total 

So, my question is whether the "MUST" is really more appropriately 
turned into a "SHOULD" guidance?  Given that we expect reordering to be 
possible (and maybe normal) over hops supporting L4S, then the 
congestion control algorithm SHOULD have mechanisms that allow it to 
perform robustly.  If it doesn't, it only hurts itself, not any other 
traffic, so there seems to be no real reason to say "MUST" (someone 
violating it doesn't break the Internet or cause interop issues, etc).  
As I understand it, this would allow the examples like DCTCP to be 
relevant for use with L4S as well.

Does Bob or anyone else have thoughts on this?