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

Sebastian Moeller <moeller0@gmx.de> Thu, 07 November 2019 17:30 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 775941209A3 for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 09:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HD4ujmhC85uu for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 09:30:07 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 59B431209C7 for <tsvwg@ietf.org>; Thu, 7 Nov 2019 09:30:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573147802; bh=ob80SUMHG/2GmqJEeWCNXbZ0bGZ1ohDIWc4gIdv0PSQ=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=JQVbxhB+SSCRPkaUYMDng4mF9YIpdZhlbQyZnXl+fHECSRW9vT+cMIcnDREub6igf fTDEWY5KT0PAez2QCYZRpgdTUcOTiFxTBrT2z9xdZbx6E+H1NhcSTqDikgcFPpHicY dj5e3qssMWQD84YvjIyKD8WwAC/jnMzJXJqSRHwo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.133] ([77.8.232.122]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkHMZ-1i51Zw1W4v-00kjH6; Thu, 07 Nov 2019 18:30:02 +0100
Date: Thu, 07 Nov 2019 18:29:51 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <48B5443E-EB56-4862-8360-E96D662D52C3@gmail.com>
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> <090EDC6E-7B69-401D-931D-E9C3101E68DD@gmail.com> <1053591400.593303.1573131284597@mail.yahoo.com> <DEF08BBB-379B-42F8-8344-9E8DA3B341C7@heistp.net> <F12EE205-7E65-42C2-B144-721E4E6CF08A@gmx.de> <48B5443E-EB56-4862-8360-E96D662D52C3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Jonathan Morton <chromatix99@gmail.com>
CC: tsvwg@ietf.org, Pete Heist <pete@heistp.net>, "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <549F5391-0D7B-4354-BA41-2A9D016B6D33@gmx.de>
X-Provags-ID: V03:K1:rnnGCkEScjuZFnGebe288b/MNtpUZf61G4kwYD8bmtrrekU8Wsx dTKClycNze3Y5VyNrg+2xWNX5ggBNU5ppcVMr4g0+CsU6XtVUQyjK7AvTS4ZKHfk/M4Cu0z z+dqG9FXV2LEOMZsNjrWAERZyOqx+BZDbzFHPYpIYGLER9VbHYePJb3aY8ttqVf3syb0wst 04HlQpIHpT5OCSeP2CaUQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:X7qkSv6X2ro=:EBH0Kl0r5C72e7E1XTmP3B YzHtfbKpEK3ppwfGQXlejcpfxumokbuR0q2askjl2BKPzob1Dn+aLzvXehgj01Z91O6wvjJ30 y4K+bfMirNyKxMN2nJuNL3XLf8btgwj9xO7Xu8BRfLvR1WJNac1Svuxju+Xe65SjPh80H6nTQ Yhh6rhhamJHob4VflkIb/c2JAyS16M5VcEPTCtpnKSTeiqG95IXDa051PM+pCsH8vYLOd0ppD OIuJG3Yzonp91SEPzMUcvo1hF5Wf5pBqiGaZQ1+Yye3rUTIaSKyTOw+zRssMHFWB0bmtIN9Og YIUE9Hd5aOL6HTnnzZZPzK+ApQUakWoIXyd6qPDUahNPwADkSrnrQsAyBNOs+80MylBiax6Z1 KxV/2taGZ1lKe35NZwgPzuWMk3qgHhHbtyw/CfGicb7Gyq1gziVg7gfcjcIKOg9o4HHEej+y6 cD6pMLEboS2IwLtQ8CYebrWI/oMhfbkmTHl+kXFdbJcj3/1qTHgWvJurvXU4NKDIqS0217Y2R +ZQF9IIrs5CHxT7XxYxGXQ6Lz1q3mp7ICjExMQo00DkxNgIlYkmknol5ih2HPWHxzzMLg72iv jmbSCA3skAQVF64UJ2Whem4Z6Ex4wN/aDVCS0lpA9IdhrMhcaprK6pM4IFjpK68hLUUdx2OI7 SpA8JkCUppnsfoZp7RUXogGmE/0ye88RMP541BOUswvtNN38g88C1NiSG1hTSBiuCA8bLI0Zr ofUvOrg9gaX64/vG2F/jXTN/coL2NioaVdGmNnGXe+JAb/lRgtD43tRMb0eQF+qdaPVDiW13W Hyv7PlXY4RUCLMbzv4sAJFZ0tU3ilZivxpFwVdyeRCA6nWmFCmC0cDoBDn18w71aOMUsmbxUl CBILivcKQE+GZxvzivIrzTF2SDB6EmGHE9uM2MvFVK3wYctal7IjyO8PfvTF/rP0Fd4zBdn1u cWdzcMZ1EEfnOI/G+lG2g15lXZrRCMl8a0TA3TED0AQrxAo5XHKdWzGsf7bajUc8Fsatc38nl 8z9Z0HEtWqqZk5CmFZ5vmDTWUHqg7Tr+N9dL9Lx8+f4d2xu1peSCx/f1VxXfVKVAppLncKuYX IklTwCjjKAASVi5APYuPUXbfk23kSBmPynZk96uoZ9Egqu36sbTZccpj2v0qxYJ8uYQfZfRZn 3t0DWur3Vk1s8fSDxjc7H8emc6WnnYwSg7vK+aFaQgun1RMi3v/SBlAeU9qoMjJbLS9kHM0P6 piXvuCJMwmzlk3gbspKB1lw4OGL3IaoS4L8KlPNJ+A6YgRxjvBouxytfsv5o=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Ub-3nv5Poq0xRlt4CGUk0ckq0Fk>
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: Thu, 07 Nov 2019 17:30:16 -0000

More below....

On November 7, 2019 6:00:38 PM GMT+01:00, Jonathan Morton <chromatix99@gmail.com> wrote:
>> On 7 Nov, 2019, at 6:47 pm, Sebastian Moeller <moeller0@gmx.de>
>wrote:
>> 
>> [SM] I guess it is worth repeating that the obvious solution to all
>of these challenges would be to fix the actual root cause of the issue,
>instead of trying to paper over the symptoms. If L4S would not try to
>make the ECT(1) and the CE codepoint do the work that would require 2
>independent bits neither issue 16 nor 17 would exist in the first
>place. I wonder how, after having eloquently argued for the requirement
>of strict isolation/separation between tcp-friendly and dctcp-style
>traffic, one could have converged on this clearly sub-optimal approach.
>
>
>> I have read the discussion of the alternatives in the L4S draft and
>while clearly none of the options is perfect, most have less
>undesirable side effects on normal traffic than the admittedly clever
>'overload ECN codepoints' variant that currently is being pushed.
>
>I'm reasonably sure that most if not all of L4S' purported goals can be
>met, without the need for these complex workarounds, by switching to
>SCE-type signalling.  If it is then still desired to implement a
>distinct traffic class for L4S traffic, that can be done by defining a
>PHB and assigning a DSCP to it.
>
>This isn't exactly rocket surgery; the KISS principle applies.
>
> - Jonathan Morton


Yes, not redefining what CE is supposed to mean, and using a new effectively unambiguous  method to signal a milder slow down command to interested listeners elegantly will remove the L4S side effects on normal traffic. At Wich point the requirement for strict isolation moves from essential to nice to have for L4S to achieve it's goals. I am sure there are workable solutions for L4S that are good enough to still merits the experiment for interested parties. IMHO the value of L4S will not be generically end 2 end anyway but will mostly consist in allowing to build dedicated low latency routes between paying parties and in that deployment model PHB/dscps should be genuinely feasible. I have high hopes that the IETF will in the end make the right decision that will reliably allow the L4S experiment to be performed in the open internet without putting normal traffic into potential risk, after all the E in IETF stands for engineering not experiments...

Sebastian