Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Jonathan Morton <> Fri, 05 July 2019 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58EDD120193 for <>; Fri, 5 Jul 2019 01:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 y9GBFe9hOCG8 for <>; Fri, 5 Jul 2019 01:51:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77DC01202BB for <>; Fri, 5 Jul 2019 01:51:14 -0700 (PDT)
Received: by with SMTP id t28so8483133lje.9 for <>; Fri, 05 Jul 2019 01:51:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ivKtyQWZwd2fx687W0UMOeYA+NTdxQGW4vq6LSFHQA4=; b=Tt9u1IgJf7c0pKAFZ5+w9KYRqdNOr6r6o/BfiQYD7F0D++PGOsBsB68hSi+QpZcBLf dMDbv0n4FPD9nN6JdbpBpobg/1J3nqVZWkAXC/mNYGTnG7RTkxp2wpNYidFYCBZJ7JQb MY0jfnrOeIVzVjEFgFz93wodcCh/bCiCPsIfEiyf7Aji+2XG54WWSeMR6DihcsF2koMr D7hT6MryX6/jtjmbsmZyXiPQadE+688LDJjEzxXif04VUAGc7xgb7YV55aOinIWiE86L UrSTreW/jimgJSUhtnDKUlrn8m9BN06Ac8U1yTzhcNEt83yAIE2Ok9FdQmFc3h7bdL7X slEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ivKtyQWZwd2fx687W0UMOeYA+NTdxQGW4vq6LSFHQA4=; b=PY39I96h4neAjZDaYlvM9WBTy0FGnium37E6BnJVOMw45hWuDfdNgUz09gA6VZMMhb ncp8vMclLkDWi7jJrcRZFSPRhC5y5rot7zL/tKKkU5SR8h/Ejs9OYMbx2L6pweuq29n+ Vg3tj/9SzD70x5b/MdO8f3v0dX7mTs01lZGu5j8+Rzm1DZUzw2R08v35WzTnaNr7RTy2 eJf5G/D6YHs+N53lM26x4bCtv7ULUwawg2V+fvuPxKTne/yarhnNBpfwlfEgHBjrJqoC HmDM80Miu6i+hSz3PHH9Sagj9uhotnXwKZUjx0CYMwZgCfkTKFNKv14stcxAvz0mxgna EWhg==
X-Gm-Message-State: APjAAAWYWNVsyiHOCtb5HzOp67RhIJCjvXHe9yAL209jD4zGNISuo7ZG I20oLYfV+RxC4oUDtKJ4BU86uso3
X-Google-Smtp-Source: APXvYqxDE3seDsf23UI8xIwiVjjrvSmB2/DWeFFO25z/y0GoopDN0efSznVfUshYTZBCGMTVlJBJHQ==
X-Received: by 2002:a2e:8696:: with SMTP id l22mr1478266lji.201.1562316672639; Fri, 05 Jul 2019 01:51:12 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id v86sm1632298lje.74.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 01:51:11 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Fri, 5 Jul 2019 11:51:10 +0300
Cc: Bob Briscoe <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
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: Fri, 05 Jul 2019 08:51:24 -0000

> On 5 Jul, 2019, at 9:46 am, De Schepper, Koen (Nokia - BE/Antwerp) <> wrote:
>>> 2: DualQ can be defeated by an adversary, destroying its ability to isolate L4S traffic.
> Before jumping to another point, let's close down your original issue. Since you didn't mention, I assume that you agree with the following, right?
>        "You cannot defeat a DualQ" (at least no more than a single Q)

I consider forcibly degrading DualQ to single-queue mode to be a defeat.  However…

>>> But that's exactly the problem.  Single queue AQM does not isolate L4S traffic from "classic" traffic, so the latter suffers from the former's relative aggression in the face of AQM activity.
> With L4S a single queue can differentiate between Classic and L4S traffic. That's why it knows exactly how to treat the traffic. For Non-ECT and ECT(0) square the probability, and for ECT(1) don't square, and it works exactly like a DualQ, but then without the latency isolation. Both types get the same throughput, AND delay. See the PI2 paper, which is exactly about a single Q.

Okay, this is an important point: the real assertion is not that DualQ itself is needed for L4S to be safe on the Internet, but for differential AQM treatment to be present at the bottleneck.  Defeating DualQ only destroys L4S' latency advantage over "classic" traffic.  We might actually be making progress here!

> I agree you cannot isolate in a single Q, and this is why L4S is better than SCE, because it tells the AQM what to do, even if it has a single Q. SCE needs isolation, L4S not.

Devil's advocate time.  What if, instead of providing differential treatment WRT CE marking, PI2 instead applied both marking strategies simultaneously - the higher rate using SCE, and the lower rate using CE?  Classic traffic would see only the latter; L4S could use the former.

> We tried years ago similar things like needed for SCE, and found that it can't work. For throughput fairness you need the squared relation between the 2 signals, but with SCE, you need to apply both signals in parallel, because you don't know the sender type. 

Yes, that's exactly what we do - and it does work.

> 	- So either the sender needs to ignore CE if it gets SCE, or ignore SCE if you get CE. The first is dangerous if you have multiple bottlenecks, and the second is defeating the purpose of SCE. Any other combination leads to unfairness (double response).

This is a false dichotomy.  We quickly realised both of those options were unacceptable, and sought a third way.

SCE senders apply a reduced CE response when also responding to parallel SCE feedback, roughly in line with ABE, on the grounds that responding to SCE does some of the necessary reduction already.  The reduced response is still a Multiplicative Decrease, so it fits with normal TCP congestion control principles.

> 	- you separate the signals in queue dept, first applying SCE and later CE, as you originally proposed, but that results in starvation for SCE.

Yes, although this approach gives the best performance for SCE when used with flow isolation, or when all flows are known to be SCE-aware.  So we apply this strategy in those cases, and move the SCE marking function up to overlap CE marking specifically for single queues.

It has been suggested that single queue AQMs are rare in any case, but this approach covers that corner case.

> Add on top that SCE makes it impossible to use DualQ, as you cannot differentiate the traffic types.

SCE is designed around not *needing* to differentiate the traffic types.  Single queues have known disadvantages, and SCE doesn't worsen them.

Meanwhile, we have proposed LFQ to cover the DualQ use case.  I'd be interested in hearing a principled critique of it.

 - Jonathan Morton