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

[Bob Briscoe <[e-mail]>]

Jake,

On first pass I don't fully get it, so I need to spend more time reading 
and re-reading once I've gone back to the refs you give (which need to 
be in my L1 cache while reading it, and they're not). But I don't have  
that time in the next 2 days. so I can't process this before the interim 
on Thu.

I'm just about to post a new rev of the ecn-l4s-id draft that I wrote 
before seeing your posting. Then I've got test results and slides to do. 
So apologies if the posting of ecn-l4s-id seems to cross your request - 
that's just an unfortunate timing clash. Please understand that posting 
a new rev is not intended as an implicit passive aggressive "No" to your 
request!


Bob

On 17/02/2020 23:27, Holland, Jake wrote:
> 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
>
>

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