[Ecn-sane] [tsvwg] Comments on L4S drafts

[Bob Briscoe]

Jonathan,

On 04/07/2019 15:03, Jonathan Morton wrote:
>> On 4 Jul, 2019, at 4:43 pm, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper at nokia-bell-labs.com> wrote:
>>
>> So conclusion:   a DualQ works exactly the same as any other single Q AQM supporting ECN !!
>> Try it, and you'll see...
> But that's exactly the problem.  Single queue AQM does not isolate L4S traffic from "classic" traffic, so the latter suffers from the former's relative aggression in the face of AQM activity.
You are assuming that the one thing we haven't done yet (fall-back to 
TCP-friendly on detection of classic ECN) won't work, whereas all the 
problems you have not addressed yet with SCE will work.

>   This isolation is the very reason why something like DualQ is proposed, so the fact that it can be defeated into this degraded single-queue mode is a genuine problem.
>
> May I direct you to our LFQ draft, published yesterday, for what we consider to be a much more robust approach, yet with similar hardware requirements to DualQ?  I'd be interested in hearing feedback.
I will certainly read. I assume you are aware that implementation 
complexity is only a small part of the objections to FQ. {Note 1}

I believe that using this to enable fine-grained congestion control 
would still rely on the semantics of the SCE style of signalling still. 
Correct?

So, for the third time of asking, can you or someone please respond to 
the 5 points that will be problematic for SCE (I listed them on 11 Mar 
2019 on tsvwg at ietf.org re-pasted from bloat@ to you & DaveT the day 
after you posted the first draft). You will not get anywhere in the IETF 
without addressing serious problems that people raise with your proposal.

I don't need to tell you that the Internet is a complex place to 
introduce anything new, especially into IP itself. If you cannot solve 
/all/ these problems, it will save everyone a lot of time if you just 
say so.

I have repeated bullets summarizing each question below (I've removed 
the one about re-purposing the receive window, which DaveT wished hadn't 
been mentioned, and added Q4 which I asked more recently). You may wish 
to start a new thread to answer some of the more substantive ones. They 
are roughly ranked in order of seriousness with Q1-3 being show-stoppers.

  * Q1. Does SCE require per-flow scheduling?
      o If so, how do you expect it to be supported on L2 links, where
        not even the IP header is accessible, let alone L4?
      o If not, how does it work?
  * Q2. How do you address the lack of ECT(1) feedback in TCP, given
    no-one is implementing the AccECN TCP option? And even if they did,
    do you have measurements on how few middleboxes / proxies, etc will
    allow traversal?
  * Q3. How do you address all the tunnel decapsulators that will
    black-hole ECT(1) marking of the outer? Do you have measurements of
    how much of a blockage to progress this will be?
  * Q4. How do you address the interaction of the two timescale dynamics
    in the SCE congestion control?
  * Q5. Can out-of-order tolerance be relaxed on links supporting SCE?
    (not a problem as such, but a lack of one of L4S's advantages)


{Note 1}: Implementation complexity is only a small part of the 
objections to FQ. One major reason is in Q1 above. I have promised a 
write-up of all the other reasons for why per-flow scheduling is not a 
desirable goal even if it can be achieved with low complexity. I've got 
it half written (as a tech report, not an Internet Draft), but it's on 
hold while other stuff takes priority for me (not least an awkwardly 
timed family vacation starting tomorrow for 10 days).


Cheers



Bob




>
>   - Jonathan Morton

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20190704/c1567a4c/attachment.html>