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

Tom Herbert <tom@herbertland.com> Sun, 08 August 2021 00:27 UTC

Return-Path: <tom@herbertland.com>
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 EBF223A0EE8 for <ipv6@ietfa.amsl.com>; Sat, 7 Aug 2021 17:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 v04uKQND5U4l for <ipv6@ietfa.amsl.com>; Sat, 7 Aug 2021 17:27:27 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 682E93A0EE1 for <ipv6@ietf.org>; Sat, 7 Aug 2021 17:27:27 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id y12so18920542edo.6 for <ipv6@ietf.org>; Sat, 07 Aug 2021 17:27:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PpjBRb976OqWP6O48tHT5/UUq1mIzq5OJR9on7FnNo8=; b=e2TmEt89B4T7ePFvmfZszatcBwquzuHblG3eqnlKEO68MK6E3oTdeHGH1D3alINrzV 1O30SLO0KfO8ujnWXRlxg+BxMGb/q7yo69UeqaNp9GEQEucISJxRM7zWOMww0nxxEczq va58XbfuLAnzmXp+7r+EjoSX8WSDMowcdPVrZNbTcEXppMDnPFbYSFXu6dmH8XHeEfKy 8Udq/wJLsRCbhFbqKt6pVNSOj5Vwm4Ht8qLR/+eanAU8TH/P+m1XG8dARidtv/G6CWaV cJPitEEsSLfeTD+kXaEI5XCAa6ahMo3MnWCcAyt4X8w4NEwxONnZ2ElTpbdn46VwQmgO pp6w==
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:content-transfer-encoding; bh=PpjBRb976OqWP6O48tHT5/UUq1mIzq5OJR9on7FnNo8=; b=IK99j0XHYkHl7AhpHgaqOqHHe4I7R0hCENUC0PreoBEY+G1e3M+h5VPprQ4mS0clUj 3IBdeUQYghw0xHVpMkkLFrh54I0r4y4gDXsAoTKkmfXpwWqx5bY3O8jp20rbxOt6JWle GcQtyEm4Jb6Un6SZ5orGjPPqXIsMasxMLaxsbVdWlwA6ZDsZA98YBtK3Yq+7MDZQbu3k 7j4lilmyIPkmzOt6ECyCcZiPOXVI81sw4yBpKGjWugn5aHsuPq/kpJAhNRA9JjqeAykz G1bTyflNAN+p+ztRH3tpUd7W0goMiwE8e7gZcJ1FHeSa30a/8827jyxnoFuIYgY61Iix y9jQ==
X-Gm-Message-State: AOAM531LXXWgC1xozP71O6MoXIzKwi7W/S2ZibMYfxAw+S9k/ks2CeZI gdC//g21Q7AtwBUGxVcS3vPpRpGGRXWuHXlbm7SAPA==
X-Google-Smtp-Source: ABdhPJwpcGYDCXFz7oRjCJ7c2Ynzm1rCdoeFW1bP/38de0XZ5M/hlTxeElJtaxu96euYVw4Tv9n20pQNrov2T0pQ4V4=
X-Received: by 2002:a05:6402:796:: with SMTP id d22mr21547457edy.57.1628382440782; Sat, 07 Aug 2021 17:27:20 -0700 (PDT)
MIME-Version: 1.0
References: <db8c1a5534e9412ebcfa37682d75f862@huawei.com> <C23D7023-B5B7-47C6-8AC5-65A98822A724@lurchi.franken.de> <CANMZLAZGawUjRhSSE_rA8AyqMx=mx1WFeJ_tZq0KVEXJd2XBfQ@mail.gmail.com> <20210807014730.GA28901@faui48f.informatik.uni-erlangen.de> <CAO42Z2yezZh5-B0PwCuNt2FUMAW-FjMK8QZ8uL4TsPhs26zziw@mail.gmail.com> <20210807151716.GA3098@faui48f.informatik.uni-erlangen.de> <CALZ3u+a_7XQ+R8mV+9KzwRwxa0riP-QD_2R69ycV0NL9jy_S3Q@mail.gmail.com> <20210807175410.GA63079@faui48f.informatik.uni-erlangen.de> <CALx6S36b33LD_hNFvptOJuny4g98=dhq3RtKsGeLx3ks-yYjFg@mail.gmail.com> <6F63D7FE-8768-4BD8-846E-61E50E44228F@lurchi.franken.de> <CALx6S36pbw2angEmDpu5DnX2nix9KgxFs7ExU17x+JXQFs23TA@mail.gmail.com> <CALZ3u+Yt2X3faSVW7K0eaxmaQy6iA6p4=f0c4E_F4CP0tfjHYw@mail.gmail.com> <CAOj+MMHu9wSuG87_vBaGNY0oU0kMu9KPFPAwcP9+eFviCMErPg@mail.gmail.com> <CALZ3u+YRfWspGYbFPQQyEGBxsS+0VhSAZq4MHWnWrMaW1HU-tQ@mail.gmail.com> <CAOj+MMF2Vr1LRin0WpBTM6UeRfi4FGQUpgp0SX4G2ftvtm23mA@mail.gmail.com> <CALZ3u+a_o8tTvBqRn2vQtrxMa8oZLA3oUgD8a_5ABg+FLPOqbg@mail.gmail.com>
In-Reply-To: <CALZ3u+a_o8tTvBqRn2vQtrxMa8oZLA3oUgD8a_5ABg+FLPOqbg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 07 Aug 2021 17:27:09 -0700
Message-ID: <CALx6S356wqZ-r0ORy20MLZ73nPjjK0GmQ8o0y4C8VQ4Az0+v8g@mail.gmail.com>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
To: Töma Gavrichenkov <ximaera@gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, 6man WG <ipv6@ietf.org>, IETF discussion list <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/88Mr0GaRyAx8Fo_GLvSYuIg3b-A>
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: Sun, 08 Aug 2021 00:27:33 -0000

On Sat, Aug 7, 2021 at 4:53 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
>
> Peace,
>
> On Sun, Aug 8, 2021 at 2:47 AM Robert Raszuk <robert@raszuk.net> wrote:
> > if someone uses anycast to establish long lasting TCP sessions (say 12h) - Good Luck !
>
> Transport sessions cannot reliably last for 12 hours on the Internet.
> That's the thing.

Toma,

Transport connections follow the end-to-end model. Transport state is
maintained at the endpoints and not in the network, and hence as long
as there remains a reachable path between the running end points the
connection is viable. That is the fundamental architecture of the
Internet. Reliability diminishes when the network is invasive in the
transport layer and E2E model is not adhered to.

>
> An application should never rely on that.  12 minutes are already kind
> of long, but 12 hours sound ridiculous.

No application relies on connections being guaranteed to be viable for
any specified amount of time, but that is not the same thing as saying
that there aren't long lived connections that productively exist or
that the network should proactively disallow long lived connections.
If a connection is still useful after 12 hours, and everyone is happy,
why tear it down and start over?

> You can achieve that over multiple paths (MP-TCP was mentioned along
> the thread) with some higher level abstraction (also subject to
> eventually break) but that's it.
>
How does anycast work with Multipath TCP? Wouldn't each subflow
potentially be routed to a different anycast host?

Tom

> This is the limitation.  There's no way 'round it.
>
> --
> Töma