[tsvwg] L4S and the RACK requirement

Wesley Eddy <wes@mti-systems.com> Tue, 12 February 2019 18:00 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E17D012E7C1 for <tsvwg@ietfa.amsl.com>; Tue, 12 Feb 2019 10:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id n4gYkPmySdAq for <tsvwg@ietfa.amsl.com>; Tue, 12 Feb 2019 10:00:51 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DF612DF71 for <tsvwg@ietf.org>; Tue, 12 Feb 2019 10:00:50 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id y20so3953509qtm.13 for <tsvwg@ietf.org>; Tue, 12 Feb 2019 10:00:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=jR1HLfK/jHoKlkjN5OrtXiasB2nn7sNjPEz/ADS94+4=; b=YXsTiH9TqzsJUugklp/UkY4rSFU+TzzeFSBWLdppgSp1t8wP6kLVJ4WyFsGzELvgOH s70pTIjGHFUYOAw/PiZkLlwK3c7ppYX7y6zo0sYdy+ynfFKiX/OXRBEINu98ENXEveUr 27vVkbSWaLY5EcbXQSNgPrzb8b/SJhebxumHm3Ojo2gcUGOnshMSLVo8KjpUrTMaOZwL YUKzeQSF/OUdrLKGjTWVAvvFXtn5j5297/ctz5wdWIJhRV1vyxZx5axvcEcwVXvqSrb6 IyTrIu03zMJao4BpLuIBp863VXJEtp+omFqbldzT9L6xS2ZT3HbSu++jtSsecmuTZCRO J8Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=jR1HLfK/jHoKlkjN5OrtXiasB2nn7sNjPEz/ADS94+4=; b=MAScjgcqP4Uv2Vdlbwhr6Njk4yyChN+2YhXLcTxBw9wlpJKMtGBLbsaho/Ar75w6se 0lXBqK1iVZBeAe/yVhTj6/9dqpj/9JB0lbQN9/lFA0nmOIydg4HCFmkVQmFPmlADWqls 3P7yKsqRDelYtgKIOk88ViHD9MBMd5+acoNg9RG725lR6pwtAaf232QyzBbmemXyKIR9 nB9Lx26fuqFhX+xyncJ313yHct+R5QV+olcdtSY1VHKICoMtiemDu0E+bsmel454jCrF jXdAyRxJtPte1B8yfrTMBm0f/Yt1P98KL91tHqpavQnR/l1WS/av6fwF2+Ta3h2jOC8V qEzQ==
X-Gm-Message-State: AHQUAuYWYYH80EWQnSPoKp/TmK1vt53D0n3L5b0sPlKFYgvPkzhPvCnQ mfb/jqJzsV0bOaIYndZXB2oHRBBdNQ8=
X-Google-Smtp-Source: AHgI3IZUn2vmtrKh6K6t0ss3Y/q7hYrN4oranJBtpV+dBWHSEkYm5fHA+RFiy9R/638DglbkmZunfg==
X-Received: by 2002:ac8:3122:: with SMTP id g31mr3932420qtb.273.1549994449715; Tue, 12 Feb 2019 10:00:49 -0800 (PST)
Received: from [] (rrcs-69-135-1-122.central.biz.rr.com. []) by smtp.gmail.com with ESMTPSA id 41sm17317230qtm.71.2019. for <tsvwg@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 10:00:48 -0800 (PST)
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <fb6d2979-a6a4-b122-a90e-4a0732ee89fa@mti-systems.com>
Date: Tue, 12 Feb 2019 13:00:47 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tvnHuSA2EfDjK7Jk42KKZrM1TW0>
Subject: [tsvwg] L4S and the RACK requirement
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2019 18:00:53 -0000

In discussion among the TSVWG chairs, we are concerned about lack of 
consensus on the requirement currently in L4S ID draft ( 
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05 ) 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?