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

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

Thanks Bob, that's a helpful clarifying comment.

I'm aware the request is a complicated one, and sorry I didn't get it in
sooner to avoid the timing clash.  I'll await your considered response
and/or questions after you've had time to look over the message more
carefully.

Best regards,
Jake

On 2/19/20, 7:17 AM, "Bob Briscoe" <[e-mail]> wrote:

    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/