From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 423A63B2A4 for ; Wed, 22 May 2024 05:37:53 -0400 (EDT) Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2e564cad1f6so90748581fa.1 for ; Wed, 22 May 2024 02:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716370672; x=1716975472; darn=lists.bufferbloat.net; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kkSoAK6SBR7LlGWYr1jMSxBBt1tRr44f1q/RQyoFfy4=; b=JFFo7LPu7ZLqZ+qOAt3szd2Kypbns975eGoxp2csoKpBkbQluEe/vlcnriTkpH84Hk ty6AWsidxTKBqTDBZtdiKvdHwnrfOPTu4Wvb8yfyi27MkX+pYseu1EmB41QZA2baAcRu xEvQhEC8TxT6sW0Wp+Fbt8/Wd4sE6f9jg2+e9iuiS8gnIlupiBsonEUvOLxl8J2+vLVA FdRNEj6xk9+UOqzQN+LDStso8PBU1n1FhYWkSmUTBuJ8/vOVqzbD1gylj3JaH6zsdd3c q8tb2XghriOm7rhRQjP79IqVxtwwj4iD48t0Css+0qvvQQ8NmBJ/qoskW61OjyTNrKA1 VFgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716370672; x=1716975472; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kkSoAK6SBR7LlGWYr1jMSxBBt1tRr44f1q/RQyoFfy4=; b=HVKlGkAhGuWwDjygOPTTzqSpAqUSF4tBiD0Tky5lK+q8cw/xKp6WQlnH5F0P/9a0G+ b/3POHJYgLRyrg1TZJ3ILlvAcV6IB8jkT1qnOPTvf/J2dlf+qMyNjVuSF37AmWs9jyig ++Elkmu1755Eo+jcIicdHJcXKG0WVEVHsA1fj/KFAKytpmXtJzOblysTLs6Q+v3hdMDe B5nKcP62Y2qF09Z3l1isG28UcjvJOZESA4SMkizvNdafvAAbZJbrudaLw9W89hbKeU3y Skw1m0RiZxNsJqcVFYSry6htUUk5BKUBIjYN+qNZxojd/Vg3vw3MFJjSckwIvaO5G0mJ WDBg== X-Forwarded-Encrypted: i=1; AJvYcCVshVBLUkwlUD0zqMCNHHWm431Y7UoHg1Nkqh/h+VPvOD6brj+O3zvRDA/hhZjoWZkCOHp//34m3CWSo8E65q1M2TTXhA07s2pGDsQ= X-Gm-Message-State: AOJu0YxehL2TDahz7XY4UzhftaGdzJnwuAjoDZtIjQF6pLQz3YCAn9c1 L1wxQpLChyI/7gUl2TFYpOSv651oWolhOF+AS36HXRwLeXIpq88w X-Google-Smtp-Source: AGHT+IEVd68MlQJilVIUuReyWrZEE11mnXsHPBxpBDxFJFyXizgCpzf84bTr+ITbWI4d5kuSmxEk6Q== X-Received: by 2002:a2e:b004:0:b0:2df:b6dd:dc24 with SMTP id 38308e7fff4ca-2e949441286mr8005841fa.8.1716370671615; Wed, 22 May 2024 02:37:51 -0700 (PDT) Received: from smtpclient.apple (37-219-25-248.nat.bb.dnainternet.fi. [37.219.25.248]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2e4d0ce2f86sm39950301fa.44.2024.05.22.02.37.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2024 02:37:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jonathan Morton In-Reply-To: Date: Wed, 22 May 2024 12:37:49 +0300 Cc: "Livingood, Jason" , Frantisek Borsik , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <11E74650-2844-42A7-96D1-3372324A9B91@gmail.com> References: <28C0EFA5-8681-41DB-AF49-E551D1AA2A0A@gmail.com> <02D6BB37-B944-478D-947F-E08EF77A7764@comcast.com> To: Sebastian Moeller X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [Bloat] "Very interesting L4S presentation from Nokia Bell Labs on tap for RIPE 88 in Krakow this week! " X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2024 09:37:53 -0000 > On 21 May, 2024, at 8:32 pm, Sebastian Moeller = wrote: >=20 >> On 21. May 2024, at 19:13, Livingood, Jason via Bloat = wrote: >>=20 >> On 5/21/24, 12:19, "Bloat on behalf of Jonathan Morton via Bloat = wrote: >>=20 >>> Notice in particular that the only *performance* comparisons they = make are between L4S and no AQM at all, not between L4S and conventional = AQM - even though they now mention that the latter *exists*. >>=20 >> I cannot speak to the Nokia deck. But in our field trials we have = certainly compared single queue AQM to L4S, and L4S flows perform = better. I don't dispute that, at least insofar as the metrics you prefer for = such comparisons, under the network conditions you also prefer. But by = omitting the conventional AQM results from the performance charts, the = comparison presented to readers is not between L4S and the current state = of the art, and the expected benefit is therefore exaggerated in a = misleading way. An unbiased presentation would alert readers to the fact that merely = deploying a conventional AQM would already eliminate nearly all of the = queue-related delay associated with a dumb FIFO, without sacrificing = much if any goodput. By doing this, they would also not expose = themselves to the risks associated with deploying L4S (see below). >>> There's also no mention whatsoever of what happens when L4S traffic = meets a conventional AQM. >>=20 >> We also tested this and all is well; the performance of classic queue = with AQM is fine. >=20 > [SM] I think you are thinking of a different case than Jonathan, not = classic traffic in the C-queue, but L4S traffic (ECT(1)) that by chance = is not hiting abottleneck employing DualQ but the traditional FIFO... > This is the case where at least TCP Prague just folds it, gives up and = goes home... >=20 > Here is Pete's data showing that, the middle two bars show what = happens when the bottleneck is not treating TCP Prague to the expected = signalling... This isn't even the case I was thinking of. Neither "classic" traffic = in the C queue (a situation which L4S has always been designed to = accommodate, however much we might debate the effectiveness of the = design), nor L4S traffic in a dumb FIFO (which, though it performs = badly, is at least "safe"), but L4S traffic in a "classic" RFC-3168 AQM, = of the type which is already deployed to some extent. This is what = exposes the fundamental incompatibility between L4S and conventional = traffic, as I have been saying from practically the moment I heard about = L4S. It's unfortunate that this case is not covered in the chart that = Sebastian linked. The situation arose because that particular chart is = focused on a performance concern, not a safety concern which was treated = elsewhere in the report. What it would show, if a fourth qdisc such as = "codel" were included (with ECN turned on), is a similar magnitude of = throughput bias as in the "pfifo" qdisc, but in the opposite direction. = Note that the bias in the "pfifo" case arises solely because Prague does = not *scale up* to high BDPs in the way that CUBIC does. - Jonathan Morton=