Re: [tsvwg] normative text in draft-ietf-tsvwg-aqm-dualq-coupled-06

[Bob Briscoe <[e-mail]>]

Koen, Greg,

Here's how I propose to derive this in a more rigorous way...

For roughly equal flow rates we shouldn't equate slowly changing p_C 
with rapidly changing p_L. So instead of
p_C = ( p_L / k )^2                  (1)
we need
     p_C = ( p_CL / k )^2                  (1)
where p_CL is a /variable/ that represents an input to p_L that changes 
as slowly as p_C.

[So, rather than /define/ p_CL as k*p', we /derive/ p_CL as follows.]

It has been proved [PI2] that it is preferable to control TCP with a 
linear PI controller, then square its output before applying it to TCP 
as a drop probability. If we call the base AQM's output p', that means:
     p_C = (p')^2                                  (2)
Substituting for p_C in Eqn (1) gives:
     p' = p_CL / k,
So we get our slow-moving input to p_L as:
     p_CL = p' * k                                  (3)

The actual probability p_L that we apply to the L queue needs to track 
the immediate L queue delay, as well as track p_CL under stationary 
conditions.
So we create an AQM that calculates a marking probability p'L as a 
function of the instantaneous L queue.
And, given the L queue has conditional strict priority over the C queue, 
whenever the L queue grows, we should apply marking probability p'_L, 
but p_L should not fall below p_CL. This suggests:
      p_L = max(p'L, p_CL)
which has also been found to work in practice.

It's a little more rigorous, but the max() function is still plucked out 
of the air.

Thoughts?


Bob

On 22/10/2018 18:17, Greg White wrote:
>
> Thanks Koen, I will look forward to reviewing the next version.
>
> -Greg
>
> *From: *"De Schepper, Koen (Nokia - BE/Antwerp)" 
> <[e-mail]>
> *Date: *Thursday, October 18, 2018 at 6:04 AM
> *To: *Greg White <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *RE: normative text in draft-ietf-tsvwg-aqm-dualq-coupled-06
>
> Greg,
>
> Part of the confusion is due to the naming scheme evolutions leaving 
> small inconsistencies in the draft. Initially we started with just p’, 
> p_L and p_C. But then trying to better name and explain all parts we 
> introduced the other names.
>
> >> My understanding is that the implementation enforces coupling only one way (from C to L) and 
> not the other, but counterbalances this by requiring that the L queue 
> get higher scheduler priority.
>
> Yes, correct. With a strict priority scheduler, a one way coupling is 
> sufficient and theoretically if there would be always sufficient 
> classic traffic, we would even not need an L4S AQM. Only when there is 
> insufficient or no classic traffic, the L4S AQM is needed. BUT as low 
> latency is important for L4S traffic, the L4S AQM is needed also to 
> immediately correct rate/latency bursts. These bursts are also 
> rippling through to the Classic queue (being not scheduled for short 
> times) but the Classic AQM is responding too slow to prevent temporary 
> queue build up in the L4S queue.
>
> >> The rationale being that p’L is expected to be much more dynamic than p_C, and that spikes in 
> p’L would negatively impact the throughput in the C queue if 
> bi-directional coupling were utilized.  Is this true?
>
> Correct, but not only the spikes would be negative. They could be 
> smoothed to compensate. But from our experiments we actually see that 
> extra L4S AQM marking has limited impact, and the possibly lower L4S 
> throughput is only required for guaranteeing low L4S latency under 
> heavy dynamic L4S traffic patterns. If there is no classic traffic, it 
> results in required underutilization, and if there is Classic traffic, 
> it benefits from the small extra available link capacity which cannot 
> be utilized by the L4S traffic. Coupling back the higher L4S 
> probability will result only in lower classic traffic throughput, 
> which removes the Classic queue, which finally will result in link 
> underutilization, which you don’t want for Classic traffic (a 
> controlled target delay is tolerated for high throughput/ full link 
> utilization).
>
> Good points, we will try to additionally clarify in the next version 
> of the draft.
>
> Thanks,
>
> Koen.
>
> *From:*Greg White <[e-mail]>
> *Sent:* Thursday, October 18, 2018 2:04 AM
> *To:* De Schepper, Koen (Nokia - BE/Antwerp) 
> <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: normative text in draft-ietf-tsvwg-aqm-dualq-coupled-06
>
> Koen,
>
> I don’t think that you necessarily need to repeat the equations in the 
> normative section.  It would be ok IMO to simply say something to the 
> effect of  “A DualQ Coupled AQM implementation MUST implement equation 
> X.” in the normative section.
>
> On the p_L vs. p_CL question (or “=” vs “<=”), I think some further 
> explanation is needed.  Both the ECN-L4S-ID draft and the background 
> in this one use “=” in comparing p_L to p_C, and I didn’t see much 
> justification given as to why this draft switches to “<=” in the 
> implementation.  The only justification I noticed was the following:
>
>    The actual L4S marking probability p_L is the maximum of the coupled
>
>    output (p_CL) and the output of a native L4S AQM (p'L), shown as
>
>    '(MAX)' in the schematic. While the output of the Native L4S AQM is
>
>    high (p'L > p_CL) it will dominate the way L traffic is marked.  When
>
>    the native L4S AQM output is lower, the way L traffic is marked will
>
>    be driven by the coupling, that is p_L = p_CL.  So, whenever the
>
>    coupling is needed, as required from equation (1):
>
>       p_C = ( p_L / k )^2.
>
> Which implies that the coupling is only needed when p’L <= p_CL, but I 
> didn’t see any further explanation for this assertion.  My 
> understanding is that the implementation enforces coupling only one 
> way (from C to L) and not the other, but counterbalances this by 
> requiring that the L queue get higher scheduler priority. The 
> rationale being that p’L is expected to be much more dynamic than p_C, 
> and that spikes in p’L would negatively impact the throughput in the C 
> queue if bi-directional coupling were utilized.  Is this true?
>
> -Greg
>
> *From: *"De Schepper, Koen (Nokia - BE/Antwerp)" 
> <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Tuesday, October 16, 2018 at 10:33 AM
> *To: *Greg White <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] 
> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> *Subject: *RE: normative text in draft-ietf-tsvwg-aqm-dualq-coupled-06
>
> Greg,
>
> Thanks for this detailed review and catching these improvements. I 
> agree that these properties should be specified explicitly and formally.
>
> Related to the  first 2 topics we should be careful to not limit 
> flexibility when mapping DualQ in a bigger picture. Probably for this 
> draft we can stick to the basic DualQ operation, and cover other uses 
> in the draft-briscoe-tsvwg-l4s-diffserv-00, so unless others 
> objecting, for me these requirements can be MUST formalized in this draft.
>
> Related to the third topic the text you quoted was indeed meant to be 
> the formal MUST specification, but I see your point. We should clearly 
> specify that the coupling equation requirement is only applicable for 
> feedback from the classic AQM to the L4S queue and does not 
> incorporate potential additional marking due to the L4S AQM. A 
> possible solution could be referring to the untagged equation 
> following equation 3: p_C = ( p_CL / k )^2 or even better to replace 
> p_L by p_CL in equation 1, right?
>
> Do you also mean that we need to repeat these equations (and figures) 
> in the normative section to give them the normative “weight”?
>
> Koen.
>
> *From:*Greg White <[e-mail] <mailto:[e-mail]>>
> *Sent:* Friday, October 12, 2018 7:36 PM
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* De Schepper, Koen (Nokia - BE/Antwerp) 
> <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> *Subject:* normative text in draft-ietf-tsvwg-aqm-dualq-coupled-06
>
> Koen, et al.,
>
> It seems that the draft on dual-queue coupled AQM could use some 
> improvements in terms of normative language.    I would think that 
> you’d want to have requirements to cover:
>
> ·The implementation MUST utilize two queues each with an AQM algorithm
>
> ·The AQM algorithm on the L queue MUST utilize ECN marking
>
> ·The two AQMs MUST implement drop/mark frequencies that are coupled 
> together according to a square function and coupling factor
>
> Without implementing these, it would seem to be hard to say that that 
> an implementation complies with the draft.
>
> On the third point, the text of the draft provides:
>
>    Whatever identifier is used for L4S experiments,
>
>    [I-D.ietf-tsvwg-ecn-l4s-id] defines the meaning of an ECN marking on
>
>    L4S traffic, relative to drop of Classic traffic.  In order to
>
>    prevent starvation of Classic traffic by scalable L4S traffic, it
>
>    says, "The likelihood that an AQM drops a Not-ECT Classic packet
>
>    (p_C) MUST be roughly proportional to the square of the likelihood
>
>    that it would have marked it if it had been an L4S packet (p_L)."  In
>
>    other words, in any DualQ Coupled AQM, the power to which p_L is
>
>    raised in Eqn. (1) MUST be 2. The term 'likelihood' is used to allow
>
>    for marking and dropping to be either probabilistic or deterministic.
>
> It isn’t clear whether that first MUST is considered a requirement, or 
> is simply an informative quote of a requirement from the other draft 
> (I presume the latter).  Also the second MUST refers to Eqn (1) which 
> is just an informative equation that provides background justification 
> for the coupled AQM.  I don’t see any requirement that states that it 
> is something that an implementer needs to actually do.  Further, it 
> seems that the schematic in Figure 1 doesn’t actually comply with that 
> expression either.  Instead it implements p_C <= ( p_L / k )^2, which 
> is not explained.
>
> -Greg
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/