[Bloat] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?)

[Michael Welzl]

I'm answering myself with an add-on thought:


> On 29 Nov 2018, at 09:08, Michael Welzl <michawe at ifi.uio.no> wrote:
> 
> 
> 
>> On 29 Nov 2018, at 08:46, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>> 
>> On Thu, 29 Nov 2018, Jonathan Morton wrote:
>> 
>>> In my view, that is the wrong approach.  Better to improve Diffserv to the point where it becomes useful in practice.
>> 
>> I agree, but unfortunately nobody has made me king of the Internet yet so I can't just decree it into existance.
> 
> Well, for what you want (re-ordering tolerance), I would think that the LE codepoint is suitable. From:
> https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06
> "there ought to be an expectation that packets of the LE PHB could be excessively delayed or dropped when any other traffic is present"
> 
> ... I think it would be strange for an application to expect this, yet not expect it to happen for only a few individual packets from a stream.

Actually, maybe this is a problem: the semantics of LE are way broader than "tolerant to re-ordering". What about applications that are reordering-tolerant, yet still latency critical?
E.g., if I use a protocol that can hand over messages out of order (e.g. SCTP, and imagine it running over UDP if that helps), then the benefit of this is typically to get messages delivered faster (without receiver-side HOL blocking)).
But then, wouldn't it be good to have a way to tell the network "I don't care about ordering" ?

It seems to me that we'd need a new codepoint for that.
But, it also seems to me that this couldn't get standardised because that standard would embrace a layer violation (caring about a transport connection), even though that has been implemented for ages.
:-(

Cheers,
Michael