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@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@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?
- If so, how do you expect it to be supported on L2 links,
where not even the IP header is accessible, let alone L4?
- 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/