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 <mich...@ifi.uio.no> wrote: >> >> >> >>> On 29 Nov 2018, at 08:46, Mikael Abrahamsson <swm...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
