--- Begin Message ---
Hi,
It's a fair question which is the best use of the last IP codepoint,
and thanks Mikael for raising some good questions.
There was a great example posted recently of why the wifi,docsis,etc.
ordering attempts aren't good enough to guarantee ordering (namely ECMP):
https://mailarchive.ietf.org/arch/msg/tsvwg/WR-UXtj9jXiYNQQIALfXQDikAjw
<h.t. Richard Scheffenegger>
I also was thinking something like RACK is a better solution in the long
term. If >80% of flows start responding better to reordering, future switches
can safely drop the reordering requirements they've adopted to work around
TCP's problems. (It's a shame that the switches ended up having to work
around that, but there was never an ordering requirement on the IP
packets, just a performance improvement to the extent you managed to
provide one.)
I think both proposals are doing almost the same thing from the point of
view of the endpoints (that is: they're providing a fine-grained congestion
signal so that sender can back off earlier and less aggressively than
multiplicative decrease).
The key difference to me is that L4S doesn't work without a dual queue.
It embeds a major design decision ("how many queues should there be at
a middle box?") into the codepoint, and comes with very narrow requirements
on the sender's congestion control.
SCE by contrast can have different responses for different congestion
controls, with more room for experimenting and fine tuning. It fits much
better with concepts like fq, which can maintain something like fairness
even when different senders are behaving differently.
Along the same lines, it's less open to abuse, because there's not an
opt-in fast lane, like with L4S. I'm worried L4S just sticks us in the
same arms race with a different queue, in the end, where everybody does
better for them and worse for the network if they can find a way to cheat
a little. So I view good fq support as more useful in the end. (And I
agree that wifi/docsis/etc. shouldn't be trying to maintain ordering
guarantees.)
I do think SCE is going to end up needing TCP options to communicate the
congestion signal, but I think this is a good first step down a long
road, and I look forward to seeing experiments that can demonstrate the
advantages, if they turn out to be what I expect here.
Cheers,
Jake
On 2019-03-11, 02:07, "Mikael Abrahamsson" <swm...@swm.pp.se> wrote:
On Mon, 11 Mar 2019, Jonathan Morton wrote:
> Seriously? I had to dig in the specs to find any mention of that, and…
> it's all about better supporting bonded links. Which can already be
It doesn't stop there. Right now DOCSIS, 3GPP networks, Wifi etc all do
ordering guarantees, so they will hold up any delivery of packets until it
can assure that none of them are delivered out of order.
Allowing these transports to re-order the packets mean they can do a
better job than they do today. You do not want to ask them to drop their
packets either because the drop rate is potentially way higher than most
transports would feel comfortable with.
> done by implementing RACK at the sender, and all you propose is that
> when L4S is in use, the extra buffering at the link layer is dropped.
I did?
> This is absolutely useless for ordinary Internet users, who are unlikely
> to have consecutive packets sufficiently closely traversing such a link
> for this reordering to exceed the 3-dupack threshold in any case - so
> you might as well delete that reordering buffer anyway, and let the
> endpoints handle it. You don't need L4S for that.
That's not my experience with wifi and how it behaves at the edge.
> endpoints (eg. using AccECN) to discover whether setting ECT(1) at the
> sender is legal. SCE does not require such negotiation (ie. a transport
> could implement it entirely at the receiver, manipulating the send rate
> via the already-standardised receive window), so should be easier to
> specify and deploy successfully.
Well, I am not convinced blowing the last codepoint on SCE has enough
merit.
--- End Message ---
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
