[tsvwg] Todays Meeting material for RTT-independence in TCP Prague

Sebastian Moeller <moeller0@gmx.de> Fri, 21 February 2020 07:59 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 890311200FF for <tsvwg@ietfa.amsl.com>; Thu, 20 Feb 2020 23:59:43 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 J070Or2aCwSk for <tsvwg@ietfa.amsl.com>; Thu, 20 Feb 2020 23:59:41 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 90E721200D6 for <tsvwg@ietf.org>; Thu, 20 Feb 2020 23:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582271976; bh=MUz6N3/a8cOaF2uTz5rYKRO/iTn3R+gh9Lg/2ML9Qiw=; h=X-UI-Sender-Class:From:Subject:Date:To; b=K8ScKVD4vUzPdTxVH6jDnlpdLdR4AraIZ1rJsO0yDnVUV9FrSJRWtsPjvWlPlJ2H3 V77s4UmIHAJdP3RHqz3tK3d+lbqBwqgpQfsY6GbgZJOVRUz9n6hhaIf8WkBThun4aw MGYM47xZtcpaxpgDjgEjsyOTuBEKSOjjkWgYtCNM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.22] ([134.76.241.253]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlf4c-1jmOeA05li-00iitt for <tsvwg@ietf.org>; Fri, 21 Feb 2020 08:59:36 +0100
From: Sebastian Moeller <moeller0@gmx.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <09E7F874-41FE-483E-B6AA-4403DD5DA4AB@gmx.de>
Date: Fri, 21 Feb 2020 08:59:34 +0100
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:5kuN8yizzkAnb2g7mwE2/q/WlvIZJEPKvrj+5AZIOyu8T1nbKJt lCT9FtbNx16NGl9HAxE2RX9iBAtxlGyJmqX+4Qaed7w7gJFOV8TchY8d2R8kJPHcg7RE8X2 vOZna1uj1OYFDRt26+d0No+7hAX5m6/s9jeAf//Z1eQ1ascPZSmRVMWIO+zrLfUxZBbC2Vx g5kZobLZwIsnKBeXSetPg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:cx4anjDb4T8=:xV/KJW0khsuJuJ7Fjm4DoH bUMPW/OMbcpHuxP5OLmW7kaP+45LrbDWHRLoeYUzTsK4kyLRLuvgjXunVh/GjCVMXuQB5yyXG 1LPO1mk20Heos5EuSAhjyQpIaAgNp288m9rRyS2eISpRDjLQVozdl3UNBcvJUJhQwqirqyBie LvdL3G+0Ughb8aLZ0MCwW4dmjg588EwZE/bjbapmAfe/gkrqtQISkSKiB6tqB0xhBtJrL5wVL XRORcIej5dPzhdMxyj1zYSOSxsToo9Q9+QDedMr6dY6tinVeXLl2O0dYkwClnjO77c3le0uJZ DIZPVNcTvDY4O2Xrd0iESWfpWsPVF0cCsDOmQMvTon3W9cW+0QAwd+u2CvDXV0huBr+KCP50L SMU1RCAUS8WxPM3hPeiizBdB9igMADaGQIsSDE3FkOQbUUawTFtE3Xfj6HJe5UlNf1BbnwZf6 a+jfe83aftAJWMC2RkMeFzw3Q/Dy10NzS5ytsMfxoLn7V6uDtwXxnOvzF/XbixsfJ2s53CxQE ih7n3QG1mGs71wEbiKbitymIxV4eSOOKcP61kDeTNXviatVK4kVcSR+neThN5AORmucTnjB9H hRmaHyayno9Wl0SD+cS8RIOuB0xJui5gcdaDv4qvmsntsEYaZY+MSVybUsmQ6kPCKtR8irtvR 35EJk66yKgGukaKAj5lGRJ3EQecbgR5eRfku+pypxKuBC4ylJOgkrfvpik5x+zs/r+2FE24uD qei23LrXtu4AHE0DnImPCuPv7MLwl5IxJEmMGSURh/IouHKaBIWqet1hfjSxEnLRzI8YGJ5ef kO6ekBoioAGOJaHK66rIOLrge8WmBM02PbtC6uOYfzxx0x5ptZyhqi2Al97LJU8N4B2wUR0nx jf3+S5mQeVWBkhVug0SdhTyex0geOg+QxLQeDb8zarJtZxjIgIc3VjbZOKVmS7EJvAGON0NlB Mpv+BmJDUCLjpDKzTkSQfL+/h+KKhESd3JasXPz+6V6mq+un5+F7oNC9WilBLOKDHdDF7dzaS Nwk4NjuHVbiI1opu8SAQxJZ/0GVI3a+OsXfH3uddmy0StGHh5YMbPAsokMMHr81DSe3JILqaB +8bTiPYUl5MNmpK5WiRK2bmfHRNuBUH22GNPKLS9p/eNebUbswjXuvvUxdjjXA32WxNuXGpz/ 1Ta2J/aFcHXoYyaCfCPh/JpTEC5PA0uIZ5WkOOdb7EhIJwOAGoilkqUiwwmU3ie/vipSZw1hv w7YYolMz2vtqTF5Q4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/KF9M4Mjij_Hq1_rQKqRZaFOx0e8>
Subject: [tsvwg] Todays Meeting material for RTT-independence in TCP Prague
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: Fri, 21 Feb 2020 07:59:43 -0000

Dear All,


after today's virtual meeting I am still pondering Koen's RTT-independence day presentation. The more I am thinking about this the more confused I get about what was actually achieved. 

Was it:
A) true RTT independence between TCP Prague flows so flows of wildly differing RTTs will share an L4S AQM's LL queue fairly?

B) class RTT independence, that is adding the so far under-explained 15 ms target for L4S's non-LL queue to the internal RTT response generation in TCP Prague (which, let me be frank would be a gross hack and solving the right problem (dualQ's failure to meet its goals robustly and reliably) at the wrong position)?

C) all of the above?

I had a look at the slides, and all I see is B) and no data for A), and IIRC the demo also focused on B), dod I miss something. If you have data for A) please share with us, because B) alone is not well-described with the RTT-independence moniker.

Question: is it just me, or do others also get uneasy when a yet un-deployed transport protocol modification (TCP Prague) grows a magic +14.5ms constant somewhere in its innards to work-around the existence of another under-explained 15ms constant somewhere in the innards of another yet un-deployed AQM, INSTEAD of simply fixing said un-deployed AQM to not require such and ugly hack in the first place? Are all L4S compliant transports expected to grow the same ~15ms constant? 
         What if in the future the dualQ AQM is superceded by something else, that for good justification* wants to implement a target of 5ms, do you envision all modified transport protocols to be changed?** 


	The fact of the matter is, the dual queue coupled AQM as currently implemented is broken, but I see


The rationale why the magic f() would have been added to TCP Prague without the need to paper over dualQ's major failure was a bit thin in Koen's presentation, so please supply me with more reasons why this is a good idea and not simply the cheapest way to paper over dualQ brokeness without actual real engineering to fix the root cause?

Also, please show how these modifications make bandwidth sharing inside the LL-queue more equitable and significantly less RTT-dependent, ideally by using a similar mix of flows like in The Good, the Bad and the WiFi: Modern AQMs in a residential setting: T.Høiland-Jørgensen, P. Hurtig, A. Brunstrom: https://www.sciencedirect.com/science/article/pii/S1389128615002479, so that your results can be compared to figure 6. Until that point I will assume that increased RTT-independence is still aspirational.

Best Regards
	Sebastian



*) I note again, that the CODEL RFC has a section that gives some rational why 5ms is a reasonable target value for flows in the 20-200ms RTT range, and that the PIE proponents have not presented any clear study demonstrating that the chosen 15ms is optimal in any dimension, which would be interesting as DCSIS-PIE actually seems to default to 10ms...


**) This is another sticking point, I have asked the L4S team repeatedly to use their test-bed (which should make testing different configurations a breeze), to measure between-class fairness and link-utilization between the LL- and the non-LL queues for short medium and long RTTs with the non-LL-queues target set to 5ms. 
         And so far all I hear is something along the lines of, if that interests me, I could do my own tests. My interpretation is that either the test bed is far less flexible and easy to use, or there is the fear that the 5ms data would reveal something unpleasant?