Re: [Codel] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft -

[Mikael Abrahamsson <swmike@swm.pp.se>]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

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.