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

[Luca Muscariello <[e-mail]>]

On Mon, Mar 18, 2019 at 9:56 AM Tilmans, Olivier (Nokia - BE/Antwerp) <
[e-mail]> wrote:

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

Right, this is what I was trying to understand.
I checked draft-white-tsvwg-nqb but the mechanism to share traffic in the
two queues
is not described. This document refers back to draft-ietf-tsvwg-l4s-arch so
I cycled back to
my starting point as there is no description of how the queueing system
works when
non marked ECNed traffic is sent  to the low latency queue.

I thought that that was described in the DOCSIS spec Greg shared, but did
not find an answer there either.





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