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

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

Hi Bob,

Cool, thanks. I will do my best to review, understand, and comment with helpful
suggestions on a section about this.

I'm eager to understand this point better, and hopeful that if an explanation
is written up where both the L4S team and the SCE team agree on the facts
about the characteristics of such a system, that it can help clear up a lot
of missing pieces of understanding at least for myself and perhaps a few others.

Best regards,
Jake

On 3/9/20, 4:44 PM, "Bob Briscoe" <[e-mail]> wrote:

    Jake,
    
    I get it now.
    
    Yes, I'd like this written up in the draft, and I have a decent amount 
    of experience with trying to get a broadly similar approach to work. I 
    have run out of time for getting it into the ecn-l4s-id before tonight's 
    deadline, so I'll take the option of writing it up by email on the list, 
    if you wouldn't mind helping to review/re-write it. Then we can include 
    it in the draft when the IETF submission servers open again.
    
    Interestingly, you might not have thought of the other possibility with 
    this approach (which is why we were pursuing it). It doesn't necessarily 
    need ECT(1) to be assigned at all. If the Classic ECN AQM Detection and 
    Fallback is acceptable, this approach ought to be able to share the 
    ECT(0) and CE field with Classic ECN. Unfortunately, it led to a greater 
    underlying level of delay in the low latency queue.
    
    Whatever. Yes, let's write this up by email.
    
    
    Bob
    
    On 19/02/2020 17:54, Holland, Jake wrote:
    > 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/
    >      
    >      
    >
    
    -- 
    ________________________________________________________________
    Bob Briscoe                               http://bobbriscoe.net/