Re: [tsvwg] L4S and the RACK requirement

Yuchung Cheng <> Wed, 13 February 2019 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49B0126C15 for <>; Tue, 12 Feb 2019 16:27:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 iWUOP_0du3jl for <>; Tue, 12 Feb 2019 16:27:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA255126C01 for <>; Tue, 12 Feb 2019 16:27:54 -0800 (PST)
Received: by with SMTP id r11so1494987itc.2 for <>; Tue, 12 Feb 2019 16:27:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IhSgIzayGLK6SsdacLcPyiRq4V4rzjHREvP82FI53MA=; b=wI9Thj/jGYwRrThFQMqfcM2BBAH9EUfB3DRtEwl5SbIXWsJUnNm821l7XZ2Yf6QFOK Krp25ett3qMX+icu0wwqY3sekPZ84XYF2U6CR9Z+mdZSrdUE4MfrFtL2MJHwtq3bob2X 5j+MzFTb/iidf6zKwABX+wbExCHyGdUXLWGjeTpxpaqnoyPcRhdUN3BNfAphl1/GV1M6 izw4XZ8SsuQgXzUwzq2IRaqi+mDrxX8fpb+kXewxNAhZK+NevSHr5Na6VWKHhOEw0PYt MlsdP8gQ1a8tWpEWEALlWOzgeNE+i0eK7kfQWZHTVg6MczPmRhH67iVINXldC1r93vj3 fWdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IhSgIzayGLK6SsdacLcPyiRq4V4rzjHREvP82FI53MA=; b=DODxD0zvjLIbrQHwVKERsiDDVNQBOlWkryPNncUgFWfBU+ZLhhkOt88K23zkWtqUAf FWyIzmxY/+pLl4aSjUR1YfqyaDJm8LdHjd3pV57Iq+zXMg0j7aVnYlvYcSSvZt7/dM8K kukWbA0R/QGfgP6hcmK3W8qfYglxDpTjmhBRCvtuEOZ5Pz3D+M4BYRHqBDYFxT4fMkFf 7zBJlyHWBj4tEVUEe+JYEI3SnaN0MjFIMG3YasymWpgcsxWpXv2bcU5lQNGCjSjxEMdO JgKt8BP1y71a3iOOkttA4p3y4xmFGaJ+Fq61sYEDqbaes3Fj68nM+X/AEIyHPTjgDUC9 FF8A==
X-Gm-Message-State: AHQUAubGN/qbzXSMzk9Gzn6Oh1S4e+KtrrJN4J6PEKcYRV0AHqwUiouC kDrL9yGkLzipsRU6kY/Gz1Yi3J4hB0VH99BTonKRvQcSlHs=
X-Google-Smtp-Source: AHgI3IaPK5hGM6wcxHrquchuzoxc5Jx64zRyb7n164Ms3X6wGri2qLvw/c49lHe8jiwV7DqXLbWcxdtLJwlpD3PJplw=
X-Received: by 2002:a5e:8f07:: with SMTP id c7mr4429686iok.242.1550017673847; Tue, 12 Feb 2019 16:27:53 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Yuchung Cheng <>
Date: Tue, 12 Feb 2019 16:27:16 -0800
Message-ID: <>
To: Wesley Eddy <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 13 Feb 2019 00:27:57 -0000

On Tue, Feb 12, 2019 at 10:01 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 (?)).
I am missing something: how does DCTCP depend a specific loss
detection mechanism (e.g. DupACK based, RACK, etc)? DCTCP is only
mandated to react to packet losses.

Linux DCTCP uses RACK by default. There's no inherent dependency of
the two either.

> 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
> sense.
> 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?