[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ECN
- Subject: ECN
- From: saku at ytti.fi (Saku Ytti)
- Date: Thu, 14 Nov 2019 13:06:36 +0200
- In-reply-to: <CACC_My99YS1cx0MdQymM6Hdi+9+raFH-=x04Z5T5M=zSEAN2Xg@mail.gmail.com>
- References: <[email protected]> <[email protected]> <CAAeewD-QF0ebOZbEr9RWf=gPCoNm2y+RisjSFJe8g0dD899g6w@mail.gmail.com> <CACC_My99YS1cx0MdQymM6Hdi+9+raFH-=x04Z5T5M=zSEAN2Xg@mail.gmail.com>
On Wed, 13 Nov 2019 at 22:57, Lukas Tribus <lists at ltri.eu> wrote:
> In fact I believe everything beyond the 5-tuple is just a bad idea to
> base your hash on. Here are some examples (not quite as straight
> forward than the TOS/ECN case here):
ACK.
> TTL:
> https://mailman.nanog.org/pipermail/nanog/2018-September/096871.html
> IPv6 flow label:
> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
> https://pc.nanog.org/static/published/meetings/NANOG71/1531/20171003_Jaeggli_Lightning_Talk_Ipv6_v1.pdf
> https://www.youtube.com/watch?v=b0CRjOpnT7w
It is unfortunate IPv6 flow label is so poorly specified, had it been
specified clearly it could have been very very good for the Internet.
Crucially sender should be able to instruct transit HOW to hash, there
should be flags in flow label used by sender to indicate that flow
label must be used for hash exclusively, not at all, inclusively with
what ever host otherwise uses. This would give sender control over
what is discreet flow.
Something like this
https://ytti.github.io/flow-label/draft-ytti-v6ops-flow-label.html
would have been nice, but unclear if it would be possible to deliver
post-fact
--
++ytti
- References:
- ECN
- From: toke at toke.dk (Toke Høiland-Jørgensen)
- ECN
- From: nanog at as397444.net (Matt Corallo)
- ECN
- From: saku at ytti.fi (Saku Ytti)
- ECN
- From: lists at ltri.eu (Lukas Tribus)