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

[Greg White <[e-mail]>]

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