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

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

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