Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

Warren Kumari <warren@kumari.net> Mon, 09 August 2021 18:55 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55F63A121B for <ipv6@ietfa.amsl.com>; Mon, 9 Aug 2021 11:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4WUeY6vnS_h for <ipv6@ietfa.amsl.com>; Mon, 9 Aug 2021 11:55:21 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2C53A11F7 for <ipv6@ietf.org>; Mon, 9 Aug 2021 11:55:20 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id h2so12885719lji.6 for <ipv6@ietf.org>; Mon, 09 Aug 2021 11:55:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sVp3xYCD5cjyWQ2CSYEpjGasW9d+pPYeIhlq6RNJmPk=; b=etIS2/BeQG3f7JZUDhAUqtc+oTXBFJQshy2UlnSVJwBc1ib1BoGF2SuKeVt9evA2/n ReFBCCKBc9e4Xg+agxWXfuYPz6ZeizpLmChVB+VNGB6yFdp+ky2x3ax+WjtfI2x1N9FF B5D/897bmjjDMk8f+k+QgGTHrGWxbVY+u5f6hDGDkDg/qh15lX/YBY/oQsNW+TrO1hYr xuGEZ3cgTuL26UsCwKyuf3ljz7Vd9P/4LB08StaArkaRhxRHCHGOqXPMYAAiXAVJExLY tW9YtM64zQ91DjnCrbhYIKJwNtSV2r6MZGf4SgmCWPnVRilr2n3pwVdfa7v0k8qjT0AJ k/Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sVp3xYCD5cjyWQ2CSYEpjGasW9d+pPYeIhlq6RNJmPk=; b=hrtUbQIb9d2RxfTeGTsX9JLUnfpL0goKEaaETj6KH3ccaROzXkUruT/WODvUKEvUse OXB3Z9zlS3PLbAQTCdcJ5CHIqnZ+j3CRlQQLB95HCid8Yqv+vQqhg0MRoq35NQvm5S36 PzjPFDKivUicoUqA+4EWAM2+Es/2qxUq3fixuJGBuWDZxf5x2a2yrkUMdVa7bSGFYrAg e/wd6l77AjHZ7sYiIm38+Z/kPpSJfhdIBLKiXsiTSgIoFig5oivg+A7QrLZ13TolbVCz frj50QnTB8jcMS8jv1nenTWzyt0CveXmydXyyD7MCr3DgOIK9cT+zvBeFybv4PxP3wpL OIkg==
X-Gm-Message-State: AOAM530vCxo7XUw3jDN3de62g/DqNxvMHTnl9eCGo0xdE+JIuKWz3HlY ya60GVO3x5Pbdar8gnJ5vEKsL43vWF0Qu7/0LBCHmQ==
X-Google-Smtp-Source: ABdhPJwUQI/IpCn3y+Iuxzi3BcxV65oaOZf6fLDzQWY5TBXl0gx+8U/q5/zzdCeS4e2K8GXh7lG0JNIAg1rUcMUzB7Y=
X-Received: by 2002:a2e:b532:: with SMTP id z18mr5838788ljm.309.1628535317068; Mon, 09 Aug 2021 11:55:17 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S36pbw2angEmDpu5DnX2nix9KgxFs7ExU17x+JXQFs23TA@mail.gmail.com> <CALZ3u+Yt2X3faSVW7K0eaxmaQy6iA6p4=f0c4E_F4CP0tfjHYw@mail.gmail.com> <CALx6S343sL0=5wUTRSXMnhSamjTTZU=DzA9Y+dbJ4NRTu0_83w@mail.gmail.com> <CALZ3u+ad6Cecp4T+wfuKVJ4ZmnQvaCSX2njFPCN8DuctrU6uew@mail.gmail.com> <CALx6S37u=y1wX8+6d8aX-6=N1MFEqO9RwxQN5zhZnS4DLM8DcA@mail.gmail.com> <CALZ3u+bHbsdzQsHOHx-6nEe6yQBbHMDhH9_PWB=WHTchB8tj5w@mail.gmail.com> <CALx6S36MpCOh2mR+cfM__ASTdn9c4CuhxUrCnUgEv1WhORLyRg@mail.gmail.com> <CALZ3u+ZyQKUJc__HWu6drNyLSCJJ8bOsLfg1B18xwB9+HMe8GA@mail.gmail.com> <CALx6S366bXkCsyEkWCONBX5kcB9JzHU=aNF9hd+wT9FcTdShFw@mail.gmail.com> <CALZ3u+aP=v_1=w1xqfEKof7Cc6Ba3pwOYV3O=0b=NxS4hRWhiA@mail.gmail.com> <YRBdZrKV+MrrhUCG@mit.edu> <CALZ3u+aBdE3Bw3_ry+CuV4tS016c4mWewJFpr0aCbBnwj70Vzg@mail.gmail.com> <a3833e04-c123-ef52-95f9-cae80a1390e7@foobar.org> <CAMm+LwiAbiK618+kY9JTLr7_mQd-E5TKyNsGqOLrGQoLzjJo=A@mail.gmail.com> <CALZ3u+bLVUZf1fTHQvAVzOnToiPcsXEyTNt56hNAXz4=-G5-6w@mail.gmail.com> <CAHw9_i+k9x1g3bcst6rHcXpesEVwnPtV6DzsFAxi8dC6CRMZPw@mail.gmail.com> <CALx6S346mqNaE+s1DH7S7RutTpzfrC5oX1No5Jb72sTvVQjtpQ@mail.gmail.com>
In-Reply-To: <CALx6S346mqNaE+s1DH7S7RutTpzfrC5oX1No5Jb72sTvVQjtpQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 09 Aug 2021 14:54:40 -0400
Message-ID: <CAHw9_i+ELJS_xqcEHM4raq+f=PZ5yw1ptfG3a6VypZmWTo11-A@mail.gmail.com>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
To: Tom Herbert <tom@herbertland.com>
Cc: Töma Gavrichenkov <ximaera@gmail.com>, 6man WG <ipv6@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Theodore Ts'o <tytso@mit.edu>, IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000014155705c924ed38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/L1UcQAEm7YizzLfljzUbV9J9q0w>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2021 18:55:35 -0000

On Mon, Aug 9, 2021 at 2:24 PM Tom Herbert <tom@herbertland.com> wrote:

> On Mon, Aug 9, 2021 at 11:09 AM Warren Kumari <warren@kumari.net> wrote:
> >
> >
> >
> > On Mon, Aug 9, 2021 at 1:08 PM Töma Gavrichenkov <ximaera@gmail.com>
> wrote:
> >>
> >> Peace,
> >>
> >> On Mon, Aug 9, 2021, 7:47 PM Phillip Hallam-Baker <
> phill@hallambaker.com> 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 networking
stack 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@ietf.org
> > 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