[tsvwg] ECN-Dualq-SCE as a documented option in l4s-id?

["Holland, Jake" <[e-mail]>]

Hi Bob, Koen, and tsvwg,

I'd like to request adding the ECN-DualQ-SCE proposal to the list of
alternative options considered for the dualq classifier, in Appendix B
of l4s-id [0].


To slightly flesh out what I'm asking for:

The proposal I'd like to see added is to use a state-based classifier for the
dualq that uses a per-flow measure of sparseness in addition to ECT to classify
packets into the low-latency queue, so that when flows do not maintain the
sparseness expected of L4S-compatible flows, their packets go to the classic
queue.


Some notes that may help when considering and/or implementing this request,
with some [numbered-references] at the bottom.

1. As I understand it, ECN-DualQ-SCE compromises on the "SHOULD be visible at
the IP layer" criteria from section 2 of l4s-id, and gains some ground (sort of)
on "SHOULD consume minimal extra codepoints".

But maybe more importantly, it comes with some other tradeoffs that might be
worth covering as similar "SHOULD" requirements in section 2.

For instance, maybe the section 2 criteria for the ideal yet unachievable l4s-id
identifier should mention "SHOULD allow for unambiguous congestion signaling to
distinguish the LL 1/p congestion signal from the classic 1/sqrt(p) signal".

This would point out more explicitly an important compromise the ECT(1) approach
makes.  (By listing it this way, I suspect it can more easily be made clear that
the requirement for a complex classic queue detection algorithm is a workaround
that provides a mitigation for compromising on this point under the ECT(1)
approach, but could be a much more trivial "received CE" check under
ECN-DualQ-SCE.).

I'll also note this approach would provide a simple answer to the
admission control questions, which may also be worth a mention in the doc.

I think adding such a section would make it more clear in the document text
what the nature of the tradeoffs are between these approaches, so the working
group can more easily make an informed consensus decision.


2. I was reviewing some of the earlier discussion on ECN-DualQ-SCE [1][2][3][4].
On reflection, it seems to me it's a mistaken claim that SCE is unsuitable for
anything other than strict FQ, and much of the previous discussion rested on
that (I think) mistaken claim.

I noticed basically because Koen pointed out that CNQ was behaving like a
dualq, during a side discussion at Singapore when Jonathan was explaining how
CNQ worked (and pointing out that it does not enforce flow rate fairness in
any remotely strict sense), and his observation stuck with me.

In light of this observation, it seems to me the ECN-DualQ-SCE concept is at
least as worthwhile a possibility to mention as the other sections in Appendix B,
and that it's especially relevant to get the issues documented  as an integrated
part of the l4s-id draft while issue #20 is under discussion [6].

However, even if this turns out to be mistaken on closer examination, I'd still
like the proposal added to l4s-id's list of classifier options, perhaps along
with a walkthrough of the reasoning for the arguments against adopting it, with
maybe pointers to the relevant publications that looked into it.


3. I think under ECN-DualQ-SCE, "measure of flow sparseness" is a pretty wide
design space, as we're seeing from some of the SCE-related work.  (So much so
that I imagine this as one of the reasonable points against adopting it...).

But I think, as Koen pointed out, CNQ seems to qualify as an example of one
approach that has an implementation (though the existing implementation may not
satisfy all the rest of the dualq requirements, I'd guess).  But as mentioned
above, from what I hear CNQ doesn't have the strict-flow-rate-fairness issue
that you've objected to in [3] and [5].

It also seems that the queue protection mechanism in the DOCSIS 3.1 MAC spec
(Annex P) would qualify as a state-based classifier that's based on a measurement
of flow sparseness?  So I'd assume that at least some level of flow-related
additional complexity in a dualq must be considered feasible?

(Or maybe feasible with mostly-untested performance?  I recall you saying you
looked into this some years ago--if you have it, it might be helpful to get a
pointer to the results showing the effect of competing classic traffic on
low-latency traffic with just ECT as classifier when a docsis-style queue
protection mechanism is in place, if there's anything like that somewhere?
I didn't see where the prior research was written up.)


4. My motivation is that I am still concerned about the ambiguous signaling in
the ECT(1) approach and its potential consequences, so I'd like at least to
see the discussion of the best available classification strategy cover the
ECN-DualQ-SCE option, for the benefit of the working group's review of the
decision.


5. I'll also note that adding this doesn't require an SCE reference, because
I think you can point to what seems to be a roughly equivalent CE(0)/CE(1)
option mentioned in section 20.2 of RFC 3168.


Thanks for considering this request.

Best regards,
Jake



References:

[0] https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-08#appendix-B

[1] An early suggestion to combine L4S with SCE's signaling:
   https://mailarchive.ietf.org/arch/msg/tsvwg/WYNurfs72tf-y-hrGHzEazg1qcI

[2] Bob's response, with a medium-detailed reasoning chain for dismissing it:
   https://mailarchive.ietf.org/arch/msg/tsvwg/nzQiSwYtDC7rFKDzhXbt5velfa0

[3] Bob's bigger, academically formatted response about FQ generally:
   http://bobbriscoe.net/projects/latency/per-flow_tr.pdf

[4] A place I agreed that SCE requires FQ:
  https://mailarchive.ietf.org/arch/msg/tsvwg/QjuQbNpW9zCbJpdLxsdPTAb1oME

  I'm retracting the statement (or if you prefer, pointing out that even the
  original came with qualifiers like "rough" and "with caveats").  I now
  think we were talking past each other, and that although I agree there is
  some per-flow state necessary to get latency benefits from SCE, this is
  different from the strict FQ that Bob's paper objects to. (At the time, I
  was thinking of this as "roughly FQ", but I now think it's materially different
  from FQ as Bob's paper describes it, based on descriptions given there.)

[5] The cited "Dismantling a Religion" paper:
  https://web.stanford.edu/class/cs244/papers/fair-ccr2007.pdf

[6] Objection to ECT(1) codepoint usage
  https://trac.ietf.org/trac/tsvwg/ticket/20