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

["Bless, Roland (TM)" <roland.bless@kit.edu>]

Hi Michael,

Am 29.11.18 um 13:12 schrieb Michael Welzl:
> I'm answering myself with an add-on thought:
> 
>> On 29 Nov 2018, at 09:08, Michael Welzl <michawe@ifi.uio.no> wrote:
>>
>>
>>
>>> On 29 Nov 2018, at 08:46, Mikael Abrahamsson <swmike@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?

Yep, the LE semantics are basically that you're expecting to just
utilize any spare capacity (which may not be available for some longer
periods). Re-ordering of LE-packets shouldn't normally be the case as
packets of a particular flow should all be in the same LE queue.

> 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.

Too few DiffServ codepoints for too many purposes available. :-)
Most of the DiffServ PHBs are observing the recommendation of RFC 2474:
"It is RECOMMENDED that PHB implementations do not introduce any packet
re-ordering within a microflow."

> 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.

Just from a logical perspective, a re-ordering property could be
_one_ attribute of a per-hop behavior (PHB), but a PHB
has very likely further properties that specify the packet
forwarding treatment. So probably re-ordering is probably
often orthogonal to other PHB features. But having a
new (best-effort + re-ordering tolerant) PHB could
be useful for some cases...

Regards,
 Roland