On Mon, Aug 9, 2021 at 2:24 PM Tom Herbert <tom@xxxxxxxxxxxxxxx> wrote:
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.
Yes.... No..... Maybe.... I cannot tell if we are in violent agreement here or not.
There are dire proclamations that IPv6 TCP anycast cannot work.... And yet there are a bunch of existing implementations where it is clearly working, and people have built their business models around it, showing that it is working fine.
I think that we are in violent agreement; the bit that gave me pause was the "that logic works both ways", which made me think that you thought I was using it to argue the other side?
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.
Yup. Nod. Fully agree.
We've actually had a really similar discussion back in 2016 -- https://mailarchive.ietf.org/arch/msg/v6ops/NLb9D5HBWDubS52EoNrdK8gqzqI/
In that thread you said:
"The flow label for a connection may change if the connection
is failing in hopes of finding a better route-- either the networkingstack detects a bad route (i.e. TCP is retransmitting) or userspace
can request a route change if it has information about path quality.
So flow labels are not necessarily persistent which probably makes
flow label filtering a bad idea at least if persistence for the
lifetime of a connection is required for that"
It's clear what the intent was (it's described in the patch as well).
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.
Indeed. 'tis been working like this for many years, and the Internet is not on fire.
Ok, so, we *are* in violent agreement :-)
W
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
> --------------------------------------------------------------------
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
-- E. W. Dijkstra
complexities of his own making.
-- E. W. Dijkstra
