Re: [tsvwg] Traffic protection as a hard requirement for NQB

Sebastian Moeller <moeller0@gmx.de> Sat, 07 September 2019 19:16 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 AEFD2120013 for <tsvwg@ietfa.amsl.com>; Sat, 7 Sep 2019 12:16:12 -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 P6IpMYB1YO8Y for <tsvwg@ietfa.amsl.com>; Sat, 7 Sep 2019 12:16:09 -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 55425120024 for <tsvwg@ietf.org>; Sat, 7 Sep 2019 12:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567883677; bh=bKCNBMQ7k+Wci6nqSvAew6WBQc30qjicNUjuRBFtnl0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=lKUp/Doe7QtcS4nQzZ58q3AdVgO8bqCi5MEY4g1GUnwLKmmSgMndGUG11tmtdMmeR JVERRrne5nJkf1u8KImhxAJnLumt267f2z0QYzD5G2BjsB0wBScLai5zJ4jOf8k/WB TPP65W1OF1LR+b+hAyeLr9TPQDWJGophPvWAIOfI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.181.49.56]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ldbqw-1iXnix116o-00ihcu; Sat, 07 Sep 2019 21: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: <E865FE52-36AB-4B5F-A4FB-A7B946A33CA1@cablelabs.com>
Date: Sat, 7 Sep 2019 21:14:34 +0200
Cc: Steven Blake <slblake@petri-meat.com>, Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <308DDF8F-6700-4E64-8500-CD3A6A070935@gmx.de>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com> <56b804ee-478d-68c2-2da1-2b4e66f4a190@bobbriscoe.net> <AE16A666-6FF7-48EA-9D15-19350E705C19@gmx.de> <CE03DB3D7B45C245BCA0D24327794936306D4F3F@MX307CL04.corp.emc.com> <50404eb0-fa36-d9aa-5e4c-9728e7cb1469@bobbriscoe.net> <1567794961.7634.64.camel@petri-meat.com> <E865FE52-36AB-4B5F-A4FB-A7B946A33CA1@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:tsdh5Dw1kqdQ/CVQfDzqm+WcU+P53f8/GgiM/X8mPsbkxz2U3ah zWV0Cd5JMi3X203TFSgFXgS9HnKARcWEGJVUfLJAzhq2P7CyJZMqNcnhhpPWRQ13/BAcpQt de/sGiR65GltSJwkSnK2+oVqyRRFLjAy/EPS36f3N2vO7b599MMuPj51k6qV8BM8rPiNt8y StQudqrDQrHolHjZc+txA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ni45J010IGI=:MZV6ZnZ3oMOrSwoE7UeZ6W zG86pA8AVb5xiWt0piHquuGSvjt8+2lbDpFuLcR3W3IKOuc8iFZ+nWJJKY2p5SVP6Xq/HO0xG VvFQveGc9Nv3ZZOLRrrYP59ZWfSzoiJlDK/SPF1QHRjOf9SBC7Hjo/LciGhEEMA//DsOIsY3G 0ncPQGT9xkAIEX3JfDsW/OLxdztGVqsZnVjwq/t1JmgLOwITT8ybg9/kUt5FPQPrWxTh4YQb9 OxSyV92AFWZlacQYUfeo8uKXmpJRFG+uu/24LLuGptoks6kcRdVVc7NHNST3sEHGngUPIOfHB luX32k62lERTOVMxy1qUvKcSMQIDGNIsLOzgMwyt+jgtyf/pyndSfL3PGODbckpOGulaBJIA4 ZhDaS39FXew4C5cAo8471TdPBZIDZwQxbMp+tyjrOJmZZySzRwe4gB7WwdoDAn0DmUdgDd0gg WEPsBaTVpFTepOwGLKAyAyMgSHd/dDAs7uNHPJ1g0AuRzkrfkm0WfEs505CQEeeYHcbv9eAce Oyccl7wDHaj5wgigC+f/W4R8HVqrSbfF787q2q8+l0Fuc8cu2KRCZ6/BS0fzC+3cDiIk4ZNNw f1zODWv40PVRSyg5ALMRS75P3zgnegHcTX6Yz2i//BQ6cdAds3VITpBsqDuVsJrTbO6LL92GP AX+YvD0aB04P7z4puLtxgjssTKbI48YrTpsYjjD5XrYF4M+4OwZ3ck/HsfAHHu6cgncPhq1R6 I4PoWlK9OyEICOBqb5OBBTrnYn0N7TF7FC94E5dXPxlNzJNZhmhM7K7v5ioGsOcvuBCjx2Z8p 9JZRWhoGRO4hs6RNYf/WxiDDM20m0malxGcWcYOpZRwMOf9WWLXPpcgAZ8zjlPQR+50Ea7Tax aN9UmUoO6unNgUqkloc29gOd7b/34k65fIMghD1QdQHil3vlpo+E2JSEkYnbBzqnMd4TmZNhN R7pGRMCSfpEJpyoAR3u9QDcaoCkyOnFxs57tDkFxrbSdKo2uLz3OWMFnwHYBGirWht+WiyNAA d+URXfkR6TXzr9Wu4SAo/OcXQWFPCB9G97gpurPXbthDTzkuhQqMQ3OF+Td1YlW+qcEqzmbnD sA03KeT3gCP1wFkrUz8dLCzVC+wAkI6ofNZutjBU6xLHjGeO21p1ExikvIpfwX42dGjsP2Y/V pBXfm4cHulioe+7SSPQKZVN2p4QbhW+j1c6vHGbPRl3Io91RNZTkR6vLn8Bx5mbT8rFujaXM5 byAj567GhbApa2y3M
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/LYiAOHg-IGVZpbVjAQOpya5sqks>
Subject: Re: [tsvwg] Traffic protection as a hard requirement for 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: Sat, 07 Sep 2019 19:16:13 -0000


> On Sep 6, 2019, at 21:53, Greg White <g.white@CableLabs.com> wrote:
> 
> [GW] comments below
>  
> From: tsvwg <tsvwg-bounces@ietf.org> on behalf of Steven Blake <slblake@petri-meat.com>
>  
> The objective as I understand it is to offer low queueing latency to non-admissioned-controlled/non-capacity-seeking traffic (NQB). First, this is only feasible if NQB traffic is naturally self-limiting to a small fraction of total traffic (e.g., < 5%). Second, existence of this NQB service should not noticeably impact the QoS of capacity-seeking (QB) traffic. Third, implementations of this NQB service should try to ensure that capacity-seeking traffic trying to utilize the NQB service gets worse service with very high probability (so that it doesn't even bother to probe).
>  
> [GW] If the WRR weight is 0.5 for each queue, then it is feasible for the NQB PHB to provide low queueing latency to NQB traffic up to 50% of the total link capacity (and more than 50% when QB traffic is not filling up the other 50%). 

	[SM] The NQB PHB is not going to provide low queueing latency to NQB traffic, the whole "trick" behind the low queueing latency, IMHO effectively is to mandate pacing and ideally synchronize all active senders such that each of their packet's arrive only shortly before its egress timeslot at the bottleneck becomes available. For Bob's examples like VoIP that trick will only work partially, as the VoIP senders will pick their sending slots based on acquisition start time and sampling rate and will not adapt to what would be ideal for the bottleneck's scheduler (VoIP being UDP there is not even a viable path from the bottleneck AQM back to the sender to synchronize them). Using NTP as a proxy for assessing synchronisation quality and jitter it seems to me that <1ms synchronization over the open internet is going to be hard given the transient nature of most flows, but hard does not equal impossible.

>  
> [GW] On the second point, you are correct, the existence of the NQB service will not noticeably impact the QoS of capacity-seeking QB traffic.  
> For example, if the NQB traffic did happen to be smooth traffic (CBR) at exactly 50% of link capacity, then with NQB, the QB traffic flows have 50% of link capacity to compete with each other for. Let’s say that competition results in (e.g.) 0.1% packet drop/mark.  On the other hand, without the NQB service, and in the presence of the same CBR flow, the capacity-seeking traffic flows similarly compete for the remaining 50% of link capacity, and settle in to the same 0.1% packet drop/mark rate (yet the CBR flow is unfortunately also subject to high queuing delay as well as 0.1% drop if the link doesn’t support ECN).  Well, being picky, if the link didn’t support ECN then I guess the capacity seeking traffic would compete for 50.1% of link capacity without the NQB PHB, as opposed to 50% with the NQB PHB, but I would argue that isn’t a “noticeable impact”.

	[SM] And now entertain the idea of a flow fair queueing system on the bottleneck which nicely would isolate the effect of CBR traffic exceeding its permitted rates from the rest of the flows...

>  
> [GW] On your third point, I agree in concept, and it is an aspect that we’ve discussed privately several times.  At the end of the day, we could not convince ourselves of an appropriate “punishment” for mismarked QB traffic, other than high packet loss in the case where QP is not implemented or potential for out-of-order delivery when QP is implemented.

	[SM] With the actual numbers from the DualQ RFC it seems that a QB flow will be able to deposit at least up to 125ms worth of packets before hitting the overload-limit, at Bob's 120 Mbps that is roughly 1.8 MB of data, quite a number of TCP flows will be done with their business before hitting that, reaping potential benefit from mis-marking themselves, without encountering negative effects from doing so.