Re: [tsvwg] Traffic protection as a hard requirement for NQB (was: WG adoption of draft-white-tsvwg-nqb!)

Sebastian Moeller <moeller0@gmx.de> Tue, 03 September 2019 09:15 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 A332A12010C for <tsvwg@ietfa.amsl.com>; Tue, 3 Sep 2019 02:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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, 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 Mf8pdMiLx1R4 for <tsvwg@ietfa.amsl.com>; Tue, 3 Sep 2019 02:15:29 -0700 (PDT)
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 8331C12081C for <tsvwg@ietf.org>; Tue, 3 Sep 2019 02:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567502077; bh=5sjXPrJROoZyHbt9CrLyMYkYhrKQuHACC3dzakcCDQE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Vb+dpET8p6asAY5FL867jvc9eauhGI/9DDtpc58yrOh7XILoePqB+WxhbsJm8dk57 fiMfEfRmnQc0fQP4sGnyGLJMb71asRkwbuqfvZ1uq4EeQG9Yh1BFB4zzu81XqcEC6G L3DL1BLBAUW6vjppLxDI90pZOeSxiJxJwaNO725M=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMoU7-1i5uEc1Vdv-008etv; Tue, 03 Sep 2019 11:14:37 +0200
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: <56b804ee-478d-68c2-2da1-2b4e66f4a190@bobbriscoe.net>
Date: Tue, 3 Sep 2019 11:14:35 +0200
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE16A666-6FF7-48EA-9D15-19350E705C19@gmx.de>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com> <56b804ee-478d-68c2-2da1-2b4e66f4a190@bobbriscoe.net>
To: Bob Briscoe <in@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:vTfFu2ax+FafemY5UWivmajZ+D8n90PcyzPEy5t2TmCMIYAlAxg sBBxDtOmi6ArSYGsE2I7igGLah56b1op9RORXmolP+LZ8wxkDriD67AiBl6GY3Syk2HvzNK GwnNcmvV9B+tvscc+hHhQpCmcfA4GnWkezkhT3yO14yHG/LbZJR02syYA6D+CNfdd4ylpKT Qx31hbOS3FtHj9pppCl0A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:j+oOlkT+uTU=:rDrPYvt7eLf6lC+NVVAErP vtFwWT0/omACiOPCc/nty6CyMPhUwzjcFVgPq2qFy9e+xjFawPRRrsjmRqhHup8Ym9dRVtfZ+ 7grF1SSEIXjtXVaFf+PUv0aAu1NziqTRaAx0CQv5QMkQcAwOLd34YOEE8LIkTlf4WflFjf1qV W2EWJUVEgr3Vf9Nr3cLvyA+Ej6JazFJqEpL8TRpTWH3dZX5k0qH+mt07JEZSP94oyy+vVkV/g g9piPtZ8cfqV5i8VT7wykFV6J6uDuoVZZLBcSppja04gmQds0xKqGQAjm2b7im++uXOQ8EcYl UoKs5Ft+aQWPWKB+DcEFYDoSUijYb3ue5C9yI7yj+GgR+QyO2sLrJy8gJqnHApkSvQxC1wJ34 DuM5IsWyDXc9aBJ2rbNj1Nv8YFsEZYRup9oAlv+rduwCU0y7cVzmW0QxsFVsiuZbtJ5WQiGQ2 yk8J8KohHJDVT8qH5Y2pjLcMMNg0ta4OvSYt0v0UtWFrn4iMuM0mZXzf/s+9XA7Auy9jODhrL VjJnDaEGSUmpvJRi2kb9leXMEHL4EIhgrcioS0+/jnNw0oBlFMN8kmx7JbNbko0pkg3payMB6 HXrQ2A2pW3Dl+KVEKlVCx6pw0jInL9CMD1J2SkDhMA6OJLndnUlJU9NGGSpGhVRwbEbfGNC0G qOA2TCFZ85JuFmrrFQZU5CMX9jhUlgAWRIHEQzS850xj+DeRMP7vj1iDNF1VCZOU2fIjc+Abc N9NGkHM6sHaDzyeZDLiQIdvCWdIyENniyWOZwLFFET9CxLCpiOUIj6FYevbXSN8nYIvEDTmxR CYlCCRedoCm7/a4nuVCzucBPLIsPGqJ6nW2PoFkpLGmouSXgUnd75nuHV+4aruf9feD5lzeDc BqW0HkbI8jmdSAfEaAAUTe0jKmKiUDZzQXDcROJiV6yvRdkS5fahbUunWspvQIoFv/SZoy9bS EXmaTCyMLFfsRlLDIkg8NOdFtyF7va5zrT7Ghx8ir6qmiBDen1dmePRx8/2RSqyYA5m7rs4CR cr6TiqfPYw4OXh4O1/wKmUZp7vnIUJ4Nb4QpluTTN6YKduTzP1mC6ikU6WsLlVB61iwBL/c2Z 9E8S7gsxfec7KYS/g2R5TFleS3imwqXAfqocL4X3myAg7ZMwrkDRdFdpwQQDU9XTDjfSOODK/ DwlT1/ATJatZ1MvaZRFbCihQ+DOCSeg8bF05bqUAMTI7ExIw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/gQNG436K8SKEYDy-EZP_sUAFSnI>
Subject: Re: [tsvwg] Traffic protection as a hard requirement for NQB (was: WG adoption of draft-white-tsvwg-nqb!)
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: Tue, 03 Sep 2019 09:15:38 -0000

Dear Bob,

allow me to chime in.

> On Sep 2, 2019, at 16:47, Bob Briscoe <in@bobbriscoe.net> wrote:
> 
> David,
> 
> Thanks for your closing remarks on the NQB adoption call. 
> You say your last point is open for discussion, so I will dive straight in to start that discussion.
> 
> On 30/08/2019 16:40, Black, David wrote:
>> 	• [snip]
>> 	• The criticisms on this list of the “queue protection” requirement in the draft are largely accurate.   The draft needs at least an Editor’s Note that this material will be revised, as while the DOCSIS mechanism is an example of how to do queue protection, it is not appropriate to require implementation of that mechanism.   A plausible plan that I have discussed with the authors is to write a set of functional/behavioral requirements for NQB “traffic protection” that can be satisfied by a “queue protection” mechanism such as the DOCSIS mechanism, or by a suitably configured FQ AQM implementation. [snip]
>>  
>> In addition, related to item 2), my expectation (which is open to further discussion) that “traffic protection” will be a “MUST” requirement, perhaps with some well-specified exceptions (including explanations of why the exceptions are ok).   This is because “traffic protection” (e.g., “queue protection” or a suitably configured FQ AQM) appears to be necessary in general to keep queue-building traffic out of the NQB traffic aggregate, as allowing such traffic degrades the properties of the NQB PHB.
> I think we should be wary of making traffic protection a hard requirement at such an early stage in our knowledge of the NQB behaviour. I believe this is a case where the market, not the IETF, ought to decide whether protection is required. 

	[SM] The draft says "... it is worthwhile to note that the NQB designation and marking would be intended to convey verifiable traffic behavior, not needs or wants." in the light of this requirement it seems obvious that a hop willing to honor that DSCP should/must actually verify the traffic behavior, no? Requiring behavior to according to a set of requirements but not enforcing these requirements seems very very optimistic.


> 
> The draft claims incentives can be aligned by an implementation being arranged to ensure that NQB traffic benefits from NQB marking and QB traffic benefits from QB marking. Incentives are hard to guess, so that may or may not be true. However, I don't think we (the tsvwg/IETF) can state categorically that it is not true.

	[SM] I would have thought it would be on those claiming a laxer enforcement model to proof that that model is sufficient?

> 
> The draft makes the point that, even if incentives are aligned, queue-building traffic could be mismarked as NQB, either accidentally or maliciously. That's a sound reason for an implementer to include traffic protection, but I don't think it's a good reason for us (the tsvwg/IETF) to require them to.
> 
> While there is no operational experience of NQB deployments, I think the market (i.e. most early-adopting operators) will want the warm feeling of some form of traffic protection. But as we get more experience we might find incentives really are aligned. And we might find accidents and malice are not a significant problem.

	[SM] @ the chairs, how hard would it be to retroactively change from a SHOULD to  a MUST? If it is easy I agree with Bob that a SHOULD would be nice, but if it is hard I would vote for a MUST as that seems to be the safer option.

> 
> So I think the current 'SHOULD' is the right call. It could be beefed up with warnings on the risks of not providing protection - not least the risk no early adopter will want to use such an implementation. 
> 
> 
> 
> As an analogy, when TCP congestion control was first developed, it was known that end-systems could run a subverted TCP algorithm or just use unresponsive UDP. At that time, the view could have been taken that per-flow scheduling would have to be a 'MUST' requirement for all Internet bottlenecks.
> As it has turned out, the Internet does have /per-user/ scheduling at bottlenecks,

	[SM] Question is this universally true? I am not 100% sure. My access link is limited by my contracted rate, but due to oversubscription there is no guarantee that on a congested link between my home and my ISP's traffic-shaper/the wider internet I get a share that reflects my "per-user" fraction of the shared capacity. 
	I fail to see any scheduler beyond my ISPs traffic shaper that has a wholistic-enough view to classify traffic based on "user" (think NATed IPv4 address, but variable length IPv6 prefixes, plus a router's ipv6/64), could you elaborate please? 

> but there has been little need for /per-flow/ scheduling for capacity sharing (yes, FQ exists, but it's not needed for capacity sharing).
> 
> In the TCP case, it turned out that a delicate balance of incentives proved sufficient to allow most Internet equipment to be simpler and cheaper. There is a poorly understood balance of incentives in the NQB case. So let's not require equipment to be more complex than it might need to be, at least not yet.

	[SM] I believe for malicious actors NQB will be a attractive DSCP as it promised to allow doing harm even at low bandwidth (just send a low average rate in lumpy bursts and I would expect an NQB-honoring L4S scheduler to get into trouble*, without requiring a large offensive traffic load, keeping it cheap and hard to detect yet sufficiently disruptive to rob the low latency queue of its intended functionality).


*) This is a hypothesis I have not confirmed in any way, but it seems to be in line with how I understand dual queue aqm to work (so it might be more of a reflection of my level of understanding and not so much of dual queue aqm). Please correct me if this seems wrong.

> 
> u
> 
> Bob
> 
> 
>>  
>> Thanks, --David (TSVWG co-chair, will be shepherd for NQB draft).
>> ----------------------------------------------------------------
>> David L. Black, Senior Distinguished Engineer
>> Dell EMC, 176 South St., Hopkinton, MA  01748
>> +1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
>> David.Black@dell.com
>> ----------------------------------------------------------------
>>  
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/