On Wed, 28 Nov 2018, Dave Taht wrote:
see ecn-sane. Please try to write a position paper as to where and why
ecn is good and bad.
if one day we could merely establish a talmud of commentary
around this religion it would help.
From my viewpoint it seems to be all about incremental deployment. We have
30 years of "crud" that things need to work with, and the worst-case needs
to be a disaster for anything that wants to deploy.
This is one thing about L4S, ETC(1) is the last "codepoint" in the header
not used, that can statelessly identify something. If anyone sees a better
way to use it compared to "let's put it in a separate queue and CE-mark it
agressively at very low queue depths and also do not care about
re-ordering so a ARQ L2 can re-order all it wants", then they need to
speak up, soon.
I actually think the "let's not care about re-ordering" would be a
brilliant thing, it'd help quite a lot of packet network types become less
costly and more efficient, while at the same time not doing blocking of
subsequent packets just because some earlier packet needed to be
retransmitted. Brilliant for QUIC for instance, that already handles this
(at least per-stream).
--
Mikael Abrahamsson email: swm...@swm.pp.se
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
