Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

Jonathan Morton <> Mon, 16 September 2019 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A16B11200DE for <>; Mon, 16 Sep 2019 01:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Status: No, score=-1.747 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, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=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 RHVw3mXIROfJ for <>; Mon, 16 Sep 2019 01:06:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F34312003F for <>; Mon, 16 Sep 2019 01:06:23 -0700 (PDT)
Received: by with SMTP id e17so32764382ljf.13 for <>; Mon, 16 Sep 2019 01:06:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1JbTd1xStmTr/9+RbUE1ogKEgxs4PknLYA4eXp/XTQQ=; b=cSdqWgu+3mwmQm3fO57tAgtKcVTUwtDVUIAKRJ9LxEB1h5Oq6hHRUmxllKxbUE1uQk jKWFUkebGNu+XE8SlO4d+qpOsqq5xOs9p4C1ei/OxP5Fx2bBHm+YRBemCD7+w6Q35vA8 mlKO2jfLX8AgXzzRDhqqeHyABjtW1XhdPabnWsIlYei+kXoKCrMVijX5WRMGVjGj3HZa temulJm2g33UBu5ux1M79LlhcuPKfzWdq9TkMSKMo8XioCToqmjBugMPO8nA802S9xIp CF2Mq/6KKud+uJDpiRFcip3Vff4nskzb5rHKXZCuEqh6PW6WoaUPgYvU0DgzW9nnKyC7 vCQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1JbTd1xStmTr/9+RbUE1ogKEgxs4PknLYA4eXp/XTQQ=; b=j7/bUqMYihnIWLQDvolH0jTJIX/+shmIdSFW7lsXtCoL3l+YsO766KCWTxg2Nz80B2 5ddUV+EsPT4r1DAVCbEa/3whI5nL1qA8DQ8wadJklZ2C7v2Qkk5v/5Aia94rY61jABbB 3MCjPK0DRGd6F23vBcez1+fVSQNed+gjbPqC1V3ElmzFZ6sL3PVmX/FDu+9PLvoK8f0c 27KZOSETssHygUJ5Om9LJpnc41YwxQy14odp4ljhjS3KBt3jwHBMBXNxuJQZrn1SHu9D IViix+ve+kGybGzDeFbkzW7+d1rh+f3FJXY/CLw12xcXXql4zN0f6ce5v8CvKlbpBsEV FKiw==
X-Gm-Message-State: APjAAAUh+r+k1nQG1c0+U0hZ2I+WX4pzuutody5vqMyz1A7DVrNM7vKk 4CmzLAatxji/+BNLmDxkZrs=
X-Google-Smtp-Source: APXvYqzlXj+s4hgZxWEA1fACtKOWyuemuIcroqRQmGG9ImDommCI9Y2CYq/VqxX4nLbablMN1YJVuw==
X-Received: by 2002:a2e:9012:: with SMTP id h18mr5587547ljg.45.1568621181285; Mon, 16 Sep 2019 01:06:21 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id y206sm8831394lfc.6.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Sep 2019 01:06:19 -0700 (PDT)
From: Jonathan Morton <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A8DCBBFB-401C-49BE-AD70-8E08FBE244D0"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 16 Sep 2019 11:06:17 +0300
In-Reply-To: <>
Cc: Pete Heist <>, "" <>
To: Sebastian Moeller <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
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, 16 Sep 2019 08:06:26 -0000

> On 16 Sep, 2019, at 10:27 am, Sebastian Moeller <> wrote:
> So it looks like my fear that L4S-flows would completely crowd out standard compliant flows in the post bottleneck FQ-AQM scenario was unfounded! The intra-L4S latency increases in that situation, however, look terrible, but since they seem restricted to all L4S flows I can certainly live with that.

Except that's not what the data shows.  In Scenarios 5 & 6, the purple traces indicate queuing in the dumb FIFO (which affects *all* traffic), and that is much more serious with L4S traffic in play than with only RFC-3168 compliant (including SCE) traffic.  For direct comparison:

Note particularly how long the purple latency spikes last.  These are measured by parallel ICMP probes, and represent what a competing, sparse, latency-sensitive flow would see.

CUBIC and Reno-SCE almost avoid latency spikes altogether.  When Reno-SCE starts up, there's a very brief spike that's definitely less than a second wide.  For each Prague startup, the spike is at least one second and up to 5 seconds wide at its base, and much taller (the first one literally disappears off the top of the graph, which is at 110ms).  Given the baseline RTT of 10ms, this is clearly unacceptable.

Note also that in the above comparison, Reno-SCE is running into a completely non-SCE network.  In particular the link FIFO and the FQ-AQM that form the actual bottlenecks are not providing SCE signals, only RFC-3168 CE marks from the FQ-AQM and not the FIFO.  This shows the advantage of maintaining full backwards compatibility.

 - Jonathan Morton