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

Bob Briscoe <in@bobbriscoe.net> Mon, 02 September 2019 14:47 UTC

Return-Path: <in@bobbriscoe.net>
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 BA1B0120143 for <tsvwg@ietfa.amsl.com>; Mon, 2 Sep 2019 07:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 llGHokGm0ARN for <tsvwg@ietfa.amsl.com>; Mon, 2 Sep 2019 07:47:07 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A587120019 for <tsvwg@ietf.org>; Mon, 2 Sep 2019 07:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lJyyfdcH6AXp4cjsg5Tu74+E3ukJALk35qVaFT8Ze0Q=; b=I3HVxdOEOGwEqYroMOq2VVxQD RiweQalOkglzI/+bbJ8ftTvWXXehEH8NI24fySMXOj7Cp5a7JzLXRXEn6T18zFRvjIfnAjStnPJhU EDmAdbO+RQA6+sQPgAALJwmm03GVsnMCcMLnyQC+2QnPgRdgJlZmBxCSwwrXBaf6WuehhNlr7Zoyz jT8RpeaAbfqgz/yeXgY+vQP2jPWuerHrlLRPxpzGRyZ5m8xwbd9LnAGZ2y2Z6oBIsZVgUVprwIjDb 6UrocwrhAXaMSats53SejYkY3HhbWn7lDycRvIF40u39dkGI1CI2YKtW8SYaJgH8mJnVk2v8VSsex 55FoFCFog==;
Received: from [31.185.128.31] (port=50340 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <in@bobbriscoe.net>) id 1i4nbk-0005F8-RO; Mon, 02 Sep 2019 15:47:05 +0100
To: "Black, David" <David.Black@dell.com>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com>
From: Bob Briscoe <in@bobbriscoe.net>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-ID: <56b804ee-478d-68c2-2da1-2b4e66f4a190@bobbriscoe.net>
Date: Mon, 2 Sep 2019 15:47:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com>
Content-Type: multipart/alternative; boundary="------------E2A0DE76C1209CB04A05779F"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/219ajvcxlaHeM3dIquCZY1v6lu4>
Subject: [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: Mon, 02 Sep 2019 14:47:11 -0000

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:
>
>  1. [snip]
>  2. 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.

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.

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.

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, 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.



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 <mailto:David.Black@dell.com>
>
> ----------------------------------------------------------------
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/