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

Sebastian Moeller <moeller0@gmx.de> Mon, 11 November 2019 00:39 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF61200E5 for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 16:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOVVN7nc7xHi for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 16:39:12 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 36E44120814 for <tsvwg@ietf.org>; Sun, 10 Nov 2019 16:39:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573432749; bh=XKipaL+hfRedCiS0DBPvIcDVuoZ4nCKAgMqkkf/CnAg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ARBXsOq6jgllGxngt5TolOgSIHX5XnTDLykEoMto7UFP+l3c1fcsQpFmxTSrL5O4L zuVj30wExyrYj/5wFKkHIcNIUqLD/hIS8d+uX9K/++WB5xLu/st79QqIvj67q9gh86 M88lHZHfR0HjS8Ne5HNPh/Ldjn07MlbAdSxHZMzQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.6.95.82]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MbzyJ-1huLFo0qqd-00dakq; Mon, 11 Nov 2019 01:33:59 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <VI1PR07MB598181251C44DEE20A133CE5E0740@VI1PR07MB5981.eurprd07.prod.outlook.com>
Date: Mon, 11 Nov 2019 01:33:56 +0100
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7A248AD-CC4F-4244-8FC7-532DB45AF2BD@gmx.de>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <B58A5572-510E-42C7-8181-42A0BE298393@gmail.com> <D2E12331-F504-4D5F-B8E7-A1A5E98DDF7E@cablelabs.com> <2275E6A5-C8F8-477F-A24A-3E6168917DDF@gmail.com> <55F724CD-6E74-40D9-8416-D1918C2008DD@cablelabs.com> <BBE7C7A9-0222-4D84-BF27-8D5CAE2F995E@gmail.com> <6f189711-ffa0-90f4-fd16-3464ba4df3ce@mti-systems.com> <4A706B11-3239-4DAC-BE85-0B4BFF2D8FF8@heistp.net> <8B28ECE4-FF4B-4BB2-ACBE-80B30708F97E@cablelabs.com> <AAEA9AC2-B8A1-4837-A7C9-8EEA21A7C523@gmx.de> <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com> <3332A911-3AA0-4986-9AA9-B97266A3337F@heistp.net> <VI1PR07MB598169BE81401DF2B4FD2CF2E07B0@VI1PR07MB5981.eurprd07.prod.outlook.com> <A95F62C3-7162-4E9A-98AD-F3C81019A512@gmx.de> <VI1PR07MB598181251C44DEE20A133CE5E0740@VI1PR07MB5981.eurprd07.prod.outlook.com>
To: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:aTv3t/IFd/rf3uuk6kCj9dZa36RI0FU2rLdu7EDUkxbTAyQvCCl MZ3bgDlhX15wjx5YjLYzJKN7nJmXKoEMA8Azlj0j82/vxIU4lOC0+v5peONLr/A+cntmo29 hpU9Pfni2+SC0f+AfdJK8gYhSYyJpq0WHmx3KCSyW3DlnUpLmXCl5Z1w3xrzgwx+vuKtyj1 2uhmfUhkWxtf4c3XJRv9g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:/tXCP3OwAWw=:GTBXcsOz1Spms+69Rj9ySo uCaIepr+SP1gTlo7rz6LIgYiBcaoPkpPRSYxcKVwDXrKpx4xFrrMKcJYiJvIwL0nqAie6iBCV Q1hXoGAu6EX7LTQi3QyVSERddf6+gMVJFq6Xo+QGTvf1+vp8Bj06n/iOzg2sAzJZIDq1HgStV V/gZ4GQAT1hqsI8QuFZsJXPbvpOta6+q17/vjOj9ujKC/KjkxaqoxPpOWnC22n+rOc2Dq6VGS CUSZjJiSwTyWZQ0Ham3E8LLEmkWyQnLRipfFAojHpjw4ffhoW6W0Y2Me8uId3gZmURH+tB22/ gq7WLh6pY4FdCs8rPaAU2x8w9N1/X7h5yr5IWxLg6nEQ5wRSCBhqSWIM5m+knHqFnq0raVouf KcUp+dCDGUQCbu3pKO7tiLDaKC3GhBPsjFRkKVMITpD0cp8AT/ulq4Z7a7ViftzM+CaN9Mxi2 L9M75qqPxu0xQbIVD3ve1AeFER4TMDKgxeDL8Pby8N7S0rP/BPoY5ch6vRp8qTaaOx8JPR2P0 QpbgdSlBEMtw+phpQemvJGuLxjEVHRCwAzSmZ/sPfWw+QXDTOpZDc931xccZCsWrIla5y81TJ Y9cLI0XX/S/0nuoQM3nGW2YhfCpDVvAtWTXMPnvD7OoLx1v0g9iNltGjR4Eo1+Ip1M7LjI0wb tnlwm3MhJoKbwOqJ4lJe9DhpbPI771ZEkiAFHTuwUZkZmyh73mC7/qWUutpIUEnR7OFNw59pJ 4XyLeFbvfUP30MlR6dpokBS3ZIyNa2IMDtmQICOEUfy6DJJCmSb+yIJLEkR8aikd1Hdocr1Ug LGhMGWJHgYfxyQ22xjNNo9vZ1grtUzHRV+meuj8A6fFNTw248PcaZGpGwMsGkKJ6hphHsH32L 5LShjTqUzMBhFPVt3k07JnVYB1JB+XR2Kx20bh1LeST6sKrmU+z+xqYjsjt0lakyGPqo2Si+S Bk7cCEgJ4P4uzPbr2eOl45abRF61a048JfxDFZ/m2z6WyY+jgIU4wnZl2lcjYRikpmwHow3dh EwPusDVudvkCE65aCXqwrCVs9WB806goyHOyCeKGJ81Rb7VMUbF/KH4u05UvtYvcaWxY7emAV nqxCV0WFQvfB8vwIPJA57Ixm6Iz4x5P5stLacZ6R04h+kbICOoGF/68a5dcDj/715gb/hUWSQ d0cOFU0sZaSmRosEq3y2oay9D5xMXldAoCaLsczhXqm2ZVGUlbUDhcuh5EZcP/Sb+jHPQOJJw S+yJci5tImZHKhI5S0JvNnSvv54yzKOxF6XWQ/lOqJPRz7s4q3iJeE4H1i6U=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Ruv1CE_h-cGpsk7vzx3NFLENDa0>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
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: Mon, 11 Nov 2019 00:39:15 -0000

Hi Oliver,

more below.

> On Nov 11, 2019, at 01:18, Tilmans, Olivier (Nokia - BE/Antwerp) <olivier.tilmans@nokia-bell-labs.com> wrote:
> 
> Hi Sebastian,
> 
>> I just stumbled over:
>> 
>> • TCP Prague will always use Accurate ECN, regardless of the
>> net.ipv4.tcp_ecn value. This eases up concurrent testing of different CCA
>> that may or may not want to use ECN (e.g., plain non-ECN cubic).
>> 
>> I assume that this is only for testing and not supposed to be the default
>> for an eventual up-stream submission of tcp prague?
> 
> To achieve its goal (low latency even in the high percentiles), a sender has
> to finely tune its sending rate to match the bottleneck queueing limit.
> - CBR-sparse-* flows have no issue doing this as they tend to under-utilize the
> link (or their service is simply broken anyway).
> - Capacity-seeking/greedy flows need a way to estimate this limit--that is what
> motivates the needs for a 1/p response with L4S.
> 
> DCTCP can achieve this estimation with an implicit, negociation-less, estimate
> as it operates in a controlled environment (both in terms of endhost configuration
> as they need to cooperate, and in terms of network behaviors, as ACK losses/thinning
> could massively impact peformances)
> 
> Given that Prague aims to be "DCTCP over the internet", it has to withstand
> middleboxes toying with the receive window, ACK thinning in WiFi/LTE/..., pure
> ACK losses, encapsulation, proxies, ... Getting this fine-grained CE estimate in
> order to deliver its service--LL even in the high percentiles, has to work in all
> cases. AccECN is at the moment the only (as far as I know) reliable way
> to get this fine-grained feedback/congestion estimate for TCP.
> QUIC has this built-in its ACK frame, so does rmcat/SCReAM.
> 
> This is similar to DCTCP forcing the use/negociation of ECN, regardless of the actual
> sysctl value, as it cannot provide its service without it (in other words, becomes
> plains reno).

	[SM] Sorry, that does not compute to me, if at all it points at a bug in dctcp that would merit fixing. In essence dctcp aims a specific niche where this can be toerated, but since yi aim for replacing all current CCs, you need to play by the rules. TCP Prague with ECN disabled should behave like Reno, it should IMHO accept that a systems admin sets policy and needs to respect the tools used for that purpose. 


> 
> Of course, anyone can decide to write its own TCP CCA that does not want to rely on
> AccECN yet somehow benefit from the marking given by the L queue, and experiment with
> it--e.g., playing with the usual latency/bandwidth tradeoff.

	[SM] I first want to be convinced by data that this whole idea actually works under real-world conditions (for short RTTs your data indicates that dualQ/TCP Prague actually does not manage to decouple bandwidth and latency), and for that purpose being able to disable the ECN/AccECN part of TCP Prague while keeping the rest seems like much better suited for A/B testing than silently ignoring the syscontrol. This, as I repeat myself too often in the L4S related threads, is not rocket science.

Best Regards
	Sebastian

> 
> 
> Best,
> Olivier