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

[Greg White <[e-mail]>]

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]>
Date: Tuesday, October 16, 2018 at 10:33 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,

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]>
Sent: Friday, October 12, 2018 7:36 PM
To: [e-mail]
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>; [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