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

Sebastian Moeller <> Sat, 07 September 2019 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAB0F1208BC for <>; Sat, 7 Sep 2019 08:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dMPH9ScayTx9 for <>; Sat, 7 Sep 2019 08:49:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7681120824 for <>; Sat, 7 Sep 2019 08:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1567871336; bh=pGVw1nVOzyzTZ00mtGdOKB6uE1i0xbSBvKMXhAdqXfs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=QdDb0+dpx8isXBLFJtOUgTGZ+FOVPUnb7b37rhEbt1FwCk1P1lvO84Kf3rpQmEyP8 ZOJ6h9PMT2r2vHs20tTgiluWnOTeE7TnNoUkB1tKbQSZL2KFz44Qfx5iWjN7SisQ5D 7AtmUmIaQNnavTYeq1NihMvwEXxpD90PPaZ8/ETA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx001 []) with ESMTPSA (Nemesis) id 0LkPBT-1ih4ZH1X8V-00cUQB; Sat, 07 Sep 2019 17:48:56 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Sat, 7 Sep 2019 17:48:53 +0200
Cc: "Black, David" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:23z1NrRhb2KuLxw5LgTSbdy/2+olhCQ1gzfxfhD3kK5gAM3HeXp mlUqshGZ7LfElp2ud0L5rVZ7/ltIBDGPCrcigSw5EqrA8w6zkN1jQ/mu/HLuuOxY6St8Sb3 R8vtvORsgOfv21XAecbmqHimunCRSoOJflphT9Xc04yIZsydjMpQFiLu08wDMUSRohVmfU0 EHhYp6nVdSUMrnqb9KWcQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:pV6QfFjAtMY=:xCIyi5LL+F9mQenAWSoD1B Kin3cy6P16A6heb+ILZBlbHGHQG+28l0a22f8F6/oeJNIiJNaXtbUhCV65uhBFDGt/ID0hbdS vXkHipH5WxNP2vRA7AV73nKYAdZCfVaAnyZYnVh3LHjLyYW5dFjKEJK+ZwrZKApp7o5MGYQ+W 7JVaOXg90D7R8RWmdjUcOo5cFzbPX+FzoIdrropkBaUP/ucRCLpR7pT1J2lfQpgctIX4atYGO b6veUMPb5wncXj/AvY4Opzw6bUkHpGqgBrmxQrgEaFmJCneVb2hS7Xd5EtuktSRTQLIS9P5hP JtJq7M46zA2YMaxnKXn7BOOTIm1s/MaPYsRp4Gqiw76uy2jNRM/cJtQpMeGr2tOrtdC9a5kwa ujkrruPd/SM2guP9fNSZ6LxAH8ayPS7z9AVaQ1X0IqMSmlfF6TwaxKSmdbUBlufBhCPqZzTA9 /yf9iQdXWn64kwDoq9Tn8y4E9kLW5r1TaE1pneVdDrkEokaMuFL8ZlFkHChyy00qYi9SpWWhf GbK2e9BfWDhV+6XO61+nZilI3sH7vPd0oT4f5YdFx3xQSRvNI62bbcZvmjKT0YAvLzMWkh8rl ro8GXUZtU4CCKfFxNVVbbAB9EgYPF1Vwfa6JvFM2X6O10qcCTNwNet4OYXCbazp+Y7AkQNnaa 85zNsyIc0tLzi9tx1CNUDsk5ywuv/ovd6Djpm0zDzxIxkJnCQoOik2bVDk2XYJ3XmCvVWRxqH vt7zHYu+D1CyfNxL96bwkJXHbiXqFsv2VaudoYfwf0pk+7QNu1uRiHp+TQij0RB9h0an5umVr Mq3aTFkxB368YyiaQSbq1pDBLgQtc/4ZXSxPG5eSdkz82XCfjXsLDwpDkb/GsTFI14WyqFMf3 Pb1OiUC2/DMPlXnUAK4K+CaUI3d5fykGzK+9MOH9ev4QtolYIf4RsS+bVRTCB/9V0AZ1e6ev1 MhWbCYXeCDpouuluaChhRMksUAXsgvXx9F2RMbHgBGB9bNgdfUIdASv1NU5oCFEFWq5fl/kd7 rppe3uDAfUnyoJKVJSMlNaii8+aYQXqlLwcNM8u58NxrXLNBDNixbpMAiL0w1V3NjLbOtCzSt yE0F4HEkw2ZzCdVQ1i1C0++NC5tc3K0eZCUsNdgs32/nUMfWndgDcU6O3Vhftz61BNTsTx4id WXL3f6G2iiY3un9Oik08PjCHeI+7fZZp+fhDP9hEUcynmwZqAItvoYAl49nj/oPdV3wZLW/cj aIXhvsid76Nzd3IZx
Archived-At: <>
Subject: Re: [tsvwg] Traffic protection as a hard requirement for NQB
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Sep 2019 15:49:45 -0000

Dear Bob,

> On Sep 5, 2019, at 20:23, Bob Briscoe <> wrote:
> ==Incentive Alignment?==
> To judge whether there's any tragedy of the commons (incentive alignment), I'll put up a straw-man NQB configuration that complies with the following requirement in the draft:
>    a useful property of nodes that support separate queues for NQB and QB
>    flows would be that for NQB flows, the NQB queue provides better
>    performance (considering latency, loss and throughput) than the QB
>    queue; and for QB flows, the QB queue provides better performance
>    (considering latency, loss and throughput) than the NQB queue.
> Background: NQB has become possible largely because Internet access link rates have typically become fast enough that the serialization delay of a packet can be sub-millisecond, and therefore a queue of a few packets introduces delay that is small relative to other non-optional sources of delay like propagation. In these cases we no longer need priority scheduling for low delay.
> Config: 
> 	• Scheduler: 
> 		• WRR with weight 0.5 for NQB on a 120Mb/s link. That gives at least 60Mb/s for NQB flows. 
> 		• Scheduler quantum: 1500B.
> 	• Buffering:
> 		• The NQB buffer is fairly shallow (30 packets or 3ms at 120Mb/s).
> 		• The QB buffer is deeper (say 200ms) with an AQM target delay of say 10ms.
> Traffic: Let's introduce some example NQB traffic:
> 	• 2 paced flows of VoIP datagrams, each avg 50B payload plus 58B of Eth/IP/UDP/RTP headers at 33pkt/s 
> 		• bit-rate: 29kb/s /flow
> 		• serialization delay: 7.2us / pkt
> 	• 2 streams of 1000B game sync datagrams at 30pkt/s => 
> 		• bit-rate: 240kb/s /flow
> 		• serialization delay: 67us / pkt
> 	• plus occasional DNSSec datagrams, worst case 1500B
> 		• serialization delay: 100us / pkt
> 	• Perhaps 540kb/s in all, which is about 0.9% of the min NQB capacity.
> Worst-case NQB queuing delay calculation for the above traffic model: 
> Each NQB flow paces out its own packets, but one might happen to arrive while a packet from any of the other NQB flows is already queued. Worst case n-1 = 4 other NQB packets queued, where n is the number of application flows. And if there's traffic in the QB queue, each NQB packet will have to wait for one quantum (100us) while the other queue is served. Worst-case NQB delay is then:
> (67us * 2 + 7.2us + 100us) + (100us * 4) = 641us, 
> It's v unlikely that this worst-case would arise, but it gives an indication of where the tail of the delay distribution will lie.

	[SM] I just re-thought this section, and believe it to be a strawman argument. 
In my reality the NQB draft states:
"7.  Relationship to L4S
   The dual-queue mechanism described in this draft is intended to be compatible with [I-D.ietf-tsvwg-l4s-arch]."

In turn [I-D.ietf-tsvwg-l4s-arch], drags in I-D.ietf-tsvwg-aqm-dualq-coupled which sizes the shared dualQ buffer to allow for 250ms at the egress bandwidth ("limit = MAX_LINK_RATE * 250 ms               % Dual buffer size"), and not 3 ms.
In the example above it is ONLY the extremely shallow buffer of 3 ms that "aligns" the incentives such that QB traffic gets unhappy in the NQB queue. So either  -D.ietf-tsvwg-aqm-dualq-coupled needs to change, or your argument above needs adaption to 250ms. And even if we would allow 50% of that for the QB queue, that still leaves 125ms. Since you are heavily involved in the other L4S drafts this is a rather surprising lack of candidness about how the NQB queue is actually supposed to be operated. 
Feel free to demonstrate again how with a 125 ms buffer (that is 0.125/((1500*8)/(120*1000^2)) = 1250 packets or 1250*1500/1000^2 = 1.875 MB, a whole lot of flows are one with their business long before they transmitted 1,8 MB)  there are no incentives for QB flows to mark themselves as NQB unless there is a stringent monitor and enforcement regime operated at the bottleneck NQB queue operating element to weed out misbehaving flows. But please plug in the numbers that the l4S family of drafts actually recommend to use, so it becomes relevant for this draft.

Best Regards