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

Jonathan Morton <> Sun, 21 July 2019 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E53B12008B for <>; Sun, 21 Jul 2019 09:00:34 -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 SqIWuoajs5w6 for <>; Sun, 21 Jul 2019 09:00:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C160C120020 for <>; Sun, 21 Jul 2019 09:00:32 -0700 (PDT)
Received: by with SMTP id v22so26843974qkj.8 for <>; Sun, 21 Jul 2019 09:00:32 -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=DCrFZULrFxmCHIHTNsi3uLlYyus+/OjuX+hafh0y7/4=; b=Vu+8P80Pvv0FumUFp1ZsDbAG/OpOUrOAJbQqf92uA3pnf2hQWRWmQrIJmiIfw/z3zd MVVQN+C0754FA9tG4ZYpiyYITL8kvrX8n2YD7u+YZvzMlS0FVLFG+RTL9rmLifqBjApu qtYbXTTYMNsfD5r7g9weaZUaoTacVi7GBEygcrXp7J1TWjEDvQ0t88O3lkYIJ5p7sP9f /Qs3VMYTy5bjohg8NEYb1ILX80mVGke7iJ8+WrjxfWxwtdHNiELz+SB7Wbykjh0CFOaY vOpPn+jk+AEydNgLl8l6iXZYDnJ/rpIWxn6/Yd3M6cdLoCm72TMMSTWieFeVJ3/Yi0UW BMGg==
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=DCrFZULrFxmCHIHTNsi3uLlYyus+/OjuX+hafh0y7/4=; b=Hgsc4pWMVcy+krkTC2mtpxvp+kYteKxoVsYK3RFce/hurBy18EJT66UCKIWM+ve2A3 +dUJUpMbDU6oM2qkAZCLaCDzaCAVI0bwB2ZAROpjtDspRPl9MjfyvKf7ApFgGer+mTC5 zlGrV2W4YMvo2n6Y5P7/lHxHZ9cE7xITb4Pci4EGlg+FJjxj6UNxBKOnK3yU7eyJRVLt BLRqAtQI0XW2KU1ScKofbdOj7q2Xe/Dbi1B6w/3RwHuLz+1M9//ExJAJBC3PD+Lu6s2M 47nxziJUim6m8nXB5c44OXfFwzAi8sry9BO17sB3PjGorECrdkS8Ez2C2Pmj3xs9lzc8 fhUQ==
X-Gm-Message-State: APjAAAXyo66CnDpcUZgFxbbhEnfYI/GfbbmU6bGFwN5NMYF4hu/6Go68 dINgNFzdkhuXMc7+PPkPXQA=
X-Google-Smtp-Source: APXvYqzMsUFgYVejyXVP/ka1lKtx5TUm2rKoK6tZWsSlfW4J52ABJZeCl9rCKRNZ0aDWyfQ052EmrA==
X-Received: by 2002:a37:b381:: with SMTP id c123mr44577277qkf.349.1563724831882; Sun, 21 Jul 2019 09:00:31 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id t2sm22151989qth.33.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 09:00:31 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Sun, 21 Jul 2019 12:00:30 -0400
Cc: Sebastian Moeller <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>, "Black, David" <>, "" <>, "" <>, Dave Taht <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Bob Briscoe <>
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: Sun, 21 Jul 2019 16:00:34 -0000

> On 21 Jul, 2019, at 7:53 am, Bob Briscoe <> wrote:
> Both teams brought their testbeds, and as of yesterday evening, Koen and Pete Heist had put the two together and started the tests Jonathan proposed. Usual problems: latest Linux kernel being used has introduced a bug, so need to wind back. But progressing.
> Nonetheless, altho it's included in the tests, I don't see the particular concern with this 'Cake' scenario. How can "L4S flows crowd out more reactive RFC3168 flows" in "an RFC3168-compliant FQ-AQM". Whenever it would be happening, FQ would prevent it.
> To ensure we're not continually being blown into the weeds, I thought the /only/ concern was about RFC3168-compliant /single-queue/ AQMs.

I drew up a list of five network topologies to test, each with the SCE set of tests and tools, but using mostly L4S network components and focused on L4S performance and robustness.

1: L4S sender -> L4S middlebox (bottleneck) -> L4S receiver.

This is simply a sanity check to make sure the tools worked.  Actually we fell over even at this stage yesterday, because we discovered problems in the system Bob and Koen had brought along to demo.  These may or may not be improved today; we'll see.

2: L4S sender -> FQ-AQM middlebox (bottleneck) -> L4S middlebox -> L4S receiver.

This is the most favourable-to-L4S topology that incorporates a non-L4S component that we could easily come up with, and therefore .  Apparently the L4S folks are also relatively unfamiliar with Codel, which is now the most widely deployed AQM in the world, and this would help to validate that L4S transports respond reasonably to it.

3: L4S sender -> single-AQM middlebox (bottleneck) -> L4S middlebox -> L4S receiver.

This is the topology of most concern, and is obtained from topology 2 by simply changing a parameter on our middlebox.

4: L4S sender -> ECT(1) mangler -> L4S middlebox (bottleneck) -> L4S receiver.

Exploring what happens if an adversary tries to game the system.  We could also try an ECT(0) mangler or a Not-ECT mangler, in the same spirit.

5: L4S sender -> L4S middlebox (bottleneck 1) -> Dumb FIFO (bottleneck 2) -> FQ-AQM middlebox (bottleneck 3) -> L4S receiver.

This is Sebastian's scenario.  We did have some discussion yesterday about the propensity of existing senders to produce line-rate bursts occasionally, and the way these bursts could collect in *all* of the queues at successively decreasing bottlenecks.  This is a test which explores that scenario and measures its effects, and is highly relevant to best consumer practice on today's Internet.

Naturally, we have tried the equivalent of most of the above scenarios on our SCE testbed already.  The only one we haven't explicitly tried out is #5; I think we'd need to use all of Pete's APUs plus at least one of my machines to set it up, and we were too tired for that last night.

 - Jonathan Morton