On Mon, Aug 9, 2021 at 11:09 AM Warren Kumari <warren@xxxxxxxxxx> wrote: > > > > On Mon, Aug 9, 2021 at 1:08 PM Töma Gavrichenkov <ximaera@xxxxxxxxx> wrote: >> >> Peace, >> >> On Mon, Aug 9, 2021, 7:47 PM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: >>> >>> We have people vigorously asserting that Linux broke IPv6 TCP over Anycast five years ago and this is serious. >>> >>> And We have people vigorously asserting that TCP over Anycast works absolutely perfectly and there are no issues. >>> >>> And they are the same people. >> >> >> a) they're not really the same people, >> >> b) no one said that TCP works _perfectly_ over anycast per se, because it's understood that perfectionism just doesn't belong in the area or engineering. >> What's been actually said is that it works just fine in a number of applications, including almost every popular application, and these applications use it this way on purpose, > > > ... including a number of content providers. > As examples (many aren't really documented), Fastly (https://docs.fastly.com/en/guides/using-fastly-with-apex-domains) and CloudFlare (https://www.cloudflare.com/learning/cdn/glossary/anycast-network/, https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/) have offered this. > Fastly and CloudFlare both have some really smart people working for them, and they collect and analyze lots of transport level stats. I suspect that they'd be surprised to hear that what they've built doesn't work reliably... > > I'm often surprised just how often we end up in discussions in the IETF where people make an assertion like "Foo will never work. Can't be done, no way, no how.", and then someone else points at a bunch of existing implementations. This feels like another instance of this. Warren, That logic works both ways. The fact that these patches in question are over five years old and no one has reported a production issue with them is inconsistent with some of the dire proclamations in this thread that anycast is broken. Note that the concerns were raised by a researcher not by any production data, and also note that the authors of the patches were from Google and Facebook which obviously have a vested interest in not creating problems on the Internet. In fact, these points are likely to be counter arguments brought up on LKML if we try to change the Linux behavior, Linux maintainers are often loathe to change a deployed default without a strong rationale that there's a real problem in deployment. Tom > > W > >> >> >> c) also, the impact of IPv6 deployment and performance issues is perfectly limited by the current poor scale of IPv6 deployment. >> And, when the existing behaviour of applications working just fine in IPv4 breaks during transition to IPv6, that's not really going to speed the transition up. >> >> -- >> Töma > > > > -- > The computing scientist’s main challenge is not to get confused by the > complexities of his own making. > -- E. W. Dijkstra > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
