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

[Luca Muscariello <[e-mail]>]

Hi Greg,

sorry for my belated follow up on this. More comments below. I cut most of
the history for readability.

Luca


On Wed, Mar 20, 2019 at 9:03 PM Greg White <[e-mail]> wrote:

> Hi Luca,
>
>
>
> First off, thank you for your review and probing questions.  I very much
> appreciate it.
>
>
>
> Now on the points where you still have concerns, either I am not
> understanding them, or you aren’t understanding my answers.  I’ve added
> some responses inline below.  Hopefully we can get to the point that we
> agree.
>
>
>
> -Greg
>
>
>
>
>
>
>
> *From: *Luca Muscariello <[e-mail]>
> *Date: *Tuesday, March 19, 2019 at 4:13 PM
> *To: *Greg White <[e-mail]>
> *Cc: *"Tilmans, Olivier (Nokia - BE/Antwerp)" <
> [e-mail]>, tsvwg IETF list <[e-mail]>
> *Subject: *Re: [tsvwg] Fwd: New Version Notification for
> draft-white-tsvwg-lld-00.txt
>
>
>
> Greg,
>
>
>
> You may be right. We may be doing different assumptions.
>
> To me the point where we disagree is that you assume that an application,
>
> to get access to the low latency queue, is not only well behaving
>
> but also sending at a very low rate compared to the link capacity.
>
>
>
> [GW]  No, that is not the assumption. The fundamental requirement is that,
> in order to have 100% of its packets remain in the low latency queue, a
> flow cannot be contributing appreciably to queuing latency.  Note, we are
> actually not describing the performance of the low latency queue as being a
> DetNet guarantee, so the requirement for 100% of packets to have
> deterministic latency does not exist.  Rather, the focus is on 99th
> percentile latency.  Nonetheless, in the abstract, a single application
> flow could send smooth (CBR) non-responsive traffic that fully utilizes the
> link capacity, and have all of that traffic utilize either queue (low
> latency or classic, depending on if it marked its packets NQB or not).
>


[LM] If a single CBR marked application can absorb say 90% of the link
capacity then what you are describing is equivalent to a strict priority
queue.
I noticed that this is one option in DualQ that is, wisely, dismissed in
the related I-D document too. Even a D/D/1 Queue with the right values can
get very
close to saturation and a single packet in the queue at most. But that is
not the kind of sharing we want because it would also contradict what you
write
in the abstract:
"LLD makes the internet experience better for latency sensitive
applications without any negative impact on other applications."
This example you make has very negative impact on other applications.



>
>
> The point I'm trying to make is that in general, we do not know that rate.
>
> As long as we have no predictable information about the amount of non
> classified
>
> traffic that can be admitted to the low latency queue, the coupling
> factor, that
>
> determines how time is shared between the two queues, cannot be set.
>
> Any value would break the stable equilibrium assumed by the system and
> therefore
>
> that much traffic has to be kicked out of the queue.
>
>
>
> [GW] In practice, as you point out, an application generally cannot know
> the link rate (nor can it know whether it is the only application).  So, in
> practice, an application that is interested in low latency has 2 options in
> order to ensure that it isn’t causing queuing delay.  One option is that it
> simply does not send traffic that is likely to exceed the available
> capacity of the link. There are a lot of applications that do just this,
> and are great candidates for being marked NQB.  (Even without dual-queue,
> this is a practical constraint for any non-responsive application that
> cares about latency or loss performance, the only additional factor in the
> low latency queue is that the constraint applies on a more instantaneous
> basis than for a deep buffered link.) Given that the application cannot
> “know” the available capacity, all non-responsive applications take on some
> risk that they have guessed wrong, and have to accept the consequences
> (latency or loss) in the case that they have.  Of course, the lower the
> sending rate, the greater the likelihood that it won’t exceed the link
> capacity. The other option is to implement a low latency scalable
> congestion control (e.g. TCP Prague).  TCP Prague can fully utilize its
> per-flow-fair share of the link capacity across a very wide range of cases
> without the need to tune any parameters in the dual-queue configuration.
> Outside that range of cases, the behavior is not catastrophic.   I’m not
> certain what you mean by “non-classified traffic” do you mean
> non-responsive (or non-congestion-controlled)? Also you used the term
> “coupling factor” which is a specific term used in dual-queue coupled AQM
> to refer to the multiplicative factor that relates the L4S ECN marking
> probability to the Classic AQM drop probability.  I don’t think that is
> what you were referring to.  I think you intended to mean the WRR weight.
> In case I am right on both counts, I thought I had explained this in my
> earlier email, but let me make it clear.  Stability is not in question.
> What you are arguing is that per-flow-fairness isn’t guaranteed in certain
> situations.   This is true, but as I pointed out, the range of conditions
> where fairness is more-or-less achieved is pretty large, and outside that
> range things aren’t so bad.  I say “more-or-less achieved” because, with
> the dual-queue, just like a single queue, flows will only tend toward
> fairness (with the caveats of RTT differences, variations in congestion
> controllers, etc.).   But, a goal of TCP Prague is to at least reduce this
> RTT dependence.
>

[LM]  Non classified traffic is traffic that is not marked. So it has to go
to the classic queue UNLESS you can classify it locally and then enqueue it
in the low latency queue even if it is not Prague.
Take WebEx, Skype, WebRTC voice as an example, w/o assuming that there is
one single voice call at the same time. Assume I have several voice calls
in progress and maybe video.
But I also do care about DNS traffic and so on that has impact on other
applications' completion time.
I am not arguing for per-flow fairness intended as per-flow rate
equalization. I'm arguing for fairness in the sense that my application is
not killed by this system by starvation.
The queue coupling factor includes also WRR weight which plays a role in
coupling both queue service times together with ECN and packet loss.
Whatever is the set of parameters used in the 2-queue systems, as long as
both queues are backlogged, ECN marking and packet loss rate have no impact
in queue scheduling time, only WRR is responsible for time sharing.
Coupling factors are used to create idle periods in the low latency queue
that are exploited by the classic queue.
Now, my point is that this approach is harmful and you cannot stabilize the
control loop as intended therefore performance will not be as expected.



>
>
> This is not a positive incentive but rather policy enforcement.
>
> This is in itself a subject of discussion.
>
>
>
> [GW] This seems to be a matter of opinion, but I’m actually not sure why
> you feel the need to make the distinction.  The low latency queue is only
> for flows that aren’t causing queuing delay.  If a flow is causing queuing
> delay then the system (and in some cases the application itself) is better
> off if the application’s packets take the classic queue.  The job of Queue
> Protection is to enforce this, and ideally create incentives for
> “correctly” marking packets.  Furthermore, the applications that are the
> best behaved are the most likely to be able to send all of their packets
> via the low latency queue, so this is an incentive. Keep in mind, that this
> isn’t DetNet.
>

[LM] I think that queue protection has to be mandatory. Not only, I think
that queue protection should also be used to classify packets. DualQ as it
is, is harmful and cannot be fixed.
A coupled queueing system where service time and switch over time is
determined by the input traffic is very difficult to stabilize.
And what I have in mind is a stochastic process not a detnet like system.
Very far from that.




>
>
>
>