Re: [tsvwg] Fwd: New Version Notification for draft-white-tsvwg-lld-00.txt

["Tilmans, Olivier (Nokia - BE/Antwerp)" <[e-mail]>]

> Is there an assumption that the low latency queue is only used by rate
> controlled flows
> that are sensitive to ECN feedback?

The L4S definitions in draft-ietf-tsvwg-l4s-arch state that L4S flow have a 
scalable CC, in order to perform bandwidth pooling (fairly) between the
L4S flows and the classic ones.
This can however be relaxed a bit, see below.

> I would assume that a low latency queue is open to flows that are non
> necessarily controlled by ECN but just exogenously rate limited by say a
> codec rate.

This is what draft draft-white-tsvwg-nqb discusses, namely also adding 
non-queue building flows in the L4S queue (e.g., non-capacity seeking
flows such as gaming, DNS traffic, pings, sparse CBR flows).

Note that the presence of such unresponsive flows in the L4S queue 
implicitly decreases the throughput of the scalable L4S flows (but not
their classic counterpart), as they have to back off on behalf of the 
non-responsive flows (but can do so without fiddling with a magic WRR 
number). This can be accounted for in the coupling factor of the queue.


Best,
Olivier


> But now it seems like this is not the case.
> 
> Thanks
> Luca
> 
> On Sun 17 Mar 2019 at 18:32, Tilmans, Olivier (Nokia - BE/Antwerp)
> <[e-mail] <mailto:olivier.tilmans@nokia-bell-
> labs.com> > wrote:
> 
> 
> 	Hi Luca,
> 
> 	> The protection mechanism assumes that one queue has soft
> priority over
> 	> the other. Strict priority would be stupid, so there must be a wfq
> weight to
> 	> schedule the classic queue less frequently. I did not find the magic
> number
> 	> that  is set in the DOCSIS specs but whatever number is chosen I
> wonder
> 	> which opitimization objective would be the foundation of that.
> 	> 10%, 20%, 30% or any number would imply that if the priority
> queue is used
> 	> at 100% utilization the other apps would get a small fraction of the
> link
> 	> capacity.
> 	>
> 	> What number is chosen and based on which calculations?
> 
> 	The protection mechanism only affect how competing packets within
> a RTT gets
> 	dequeued. In this instance, a WRR protects the classic flows from
> 	unresponsive/misclassified L4S flows, at the expense of the other
> L4S flows.
> 
> 	It does not affect the overall throughput of the flows when
> measuring it over a
> 	timeframe of a few Tupdate interval (e.g., 16ms). Indeed, the core of
> the
> 	DualPI2 AQM is a PIE2 controller computing the random
> drop/marking probability
> 	based on the classic queue. This probability is then also used as base
> to mark L4S
> 	flows, albeit with a quadratic relationship (i.e., for the same base
> probability, the
> 	L4S flows are marked much more often than the classic ones).
> 
> 	Consequently, whenever L4S traffic causes the classic queue to build
> up (even
> 	slightly above the PIE2 target), its marking probability drastically
> increases as the
> 	PIE2 controller reacts. As the L4S flows have scalable CCs (i.e.,
> understand how to
> 	leverage multiple CE marks per RTT), they reduce their cwnd
> accordingly within
> 	 a RTT (which is much smaller than the classic flows' RTT).
> 
> 	In other words, L4S senders end up slowing down themselves (to a
> point where
> 	the L4S queue is empty for most of the transmission slots) to allow
> the classic
> 	queue to drain, and this reaction is the result of a much faster
> control-loop than
> 	the one used by the classic sender.
> 
> 	There are thus no magic number per say for the WRR ratio. §4.1.4 of
> 	 draft-ietf-tsvwg-aqm-dualq-coupled explains the guidelines to pick
> one.
> 
> 	Note that the exact throughput ratio between L4S and classic flows
> can be
> 	tweaked using a coupling factor, as explained in appendix C. of
> 	 draft-ietf-tsvwg-aqm-dualq-coupled.
> 
> 	I hope this was clear enough.
> 
> 
> 	Best,
> 	Olivier
>