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

Tom Herbert <tom@herbertland.com> Sat, 07 August 2021 19:41 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 1D3123A0CD8 for <ipv6@ietfa.amsl.com>; Sat, 7 Aug 2021 12:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 C4v4rpMdHXhF for <ipv6@ietfa.amsl.com>; Sat, 7 Aug 2021 12:41:35 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 C67D33A0CD6 for <ipv6@ietf.org>; Sat, 7 Aug 2021 12:41:34 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id gs8so21369800ejc.13 for <ipv6@ietf.org>; Sat, 07 Aug 2021 12:41:34 -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; bh=vF/7Qn1UF+DIsxnNsPDpTTsweYRLVuY1PR92mfw4198=; b=nrnhh6GQPDMLPq/o/Px2ufrOQPmkXiFi1FPIOiSBS/978B67OIZFvmrPTClHTGXorj fqIR2malpiC4BSURqRlQjdSAW29zm3FB3Agrcj7dfqAbsRRazouivnYe/L3+3t5f2CP/ SepHYHsHUOQpL6SY206wGCvOP1H3zeXe/kAnNVa4SHPRfy9mjCM56tpYn5ClLQONsqGP LmN3Scje/Z3rv0DR6heNjRVRXrxTnQDfK9ZWZ8LVPwfMu1LyCVD1WmUxqpLcsO+yYzL0 6WXHGYVzHMRTIjgTsR+Z8ehMrk1dNckdfQBp1pKi5S+4og2qS7BgarKG5Eieuga9vgK/ WWYw==
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=vF/7Qn1UF+DIsxnNsPDpTTsweYRLVuY1PR92mfw4198=; b=TFIimDL78icO9zrg5ZItrbJBKOlsjsJrM0Liu/NPNH8r3KAXWe9e4+MCSDpVggf5/E KSom46rygJmGx65tm8mdBw/M2QrbfC26VJSBJlheWheOTDOapss4bUS7ENj6VoY/Gmo3 V3cO2LW0UpvjE1bXqe1XHFuIcKeQyKO5dea5FEZwedsXLZVsg9tmw/W/nKdnoCYbsGf5 RsA6W/MknZRwLKHOey7pD3z6b15//TLjlMdWWO5VyNGTPtM63bq/3dzMkKR34b13/oup 7IKAh9ukTVcYtv61Y6GCHY0sK5Uv82Qrl5+UbPLm3ZlKfbEv1pgrDp8oxXapyTwh9rx7 Ir5g==
X-Gm-Message-State: AOAM532hjU6v+6GnyEkR9Rw0FQgEjvOPbqua0Oz5TDogA/HG9C8DxYn7 krRzpbv7ssS4wtTrvS8vz2jjM6e7tvp9gXuctni+vg==
X-Google-Smtp-Source: ABdhPJzSFiknIngeoI+c+fVlOisIKaMElZNDMXircHH0hE0dPSQnzrr5pL2FkXU24n23T99VV+vr+mZmPEAVom0iFjA=
X-Received: by 2002:a17:906:31cf:: with SMTP id f15mr15746280ejf.272.1628365292024; Sat, 07 Aug 2021 12:41:32 -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>
In-Reply-To: <20210807175410.GA63079@faui48f.informatik.uni-erlangen.de>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 07 Aug 2021 12:41:18 -0700
Message-ID: <CALx6S36b33LD_hNFvptOJuny4g98=dhq3RtKsGeLx3ks-yYjFg@mail.gmail.com>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
To: Toerless Eckert <tte@cs.fau.de>
Cc: Töma Gavrichenkov <ximaera@gmail.com>, 6man WG <ipv6@ietf.org>, IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cbcf0405c8fd56b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/d53NBTQ3t9Poxk0giXJVq4HRaI4>
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: Sat, 07 Aug 2021 19:41:40 -0000

On Sat, Aug 7, 2021, 10:55 AM Toerless Eckert <tte@cs.fau.de> wrote:

>
> Sure, that is the basic recommendation,
> but let me play devils advocate (linux developer):
>
> rfc6437: "However, a flow is not necessarily 1:1 mapped to a transport
> connection"
>
> Aka: what linux does is a perfect lightweight form of
> MP_TCP just without the overhead of different IP addresses
> or port numbers to identify different flows. Just different
> IPv6 flow labels. And in MP-TCP it would of course be perfectly
> legitimate to use two flows sequentially, e.g.: when one flow
> has RTO issues, using the second flow. Thats just a transport
> protocol policy choice.
>
> In other words: linux does not violate this SHOULD because it really
> uses two different flows.
>

Correct, it's the host prerogative to set the flow as it sees fits.
Generally, we want the flow label to be consistent for the lifetime of the
flow, that is why the flow label is only changed at RTO when the connection
is failing. So this is really intended as a last ditch effort to salvage a
failing connection.

As for relying on the network to fix problems, the host cannot assume that.
The host has detected a problem with a connection's path, there is no
reason to believe that the networks, or networks, in the path will even
detect the problem much less fix it quickly. It would be nice if the host
had a standard means to report to the network that it sees a problem, but
that doesn't exist.

Also, as the subject states these patches have been in Linux and deployment
for 5 years now. The claim that it kills anycast seems overly melodramatic.
Is there any real data on the problem?

I'll also point out that any route change in the network could also have
the same effect. If anycast, or other stateful mechanisms, requires that
all packets of transport flow are routed consistently for the lifetime of a
flow then inevitably failures will occur. Consistent outing per flow is
only best effort and not a standard requirement.

This flow label modulation patches  were presented in routing area WG at
IETF 111. The intent is to document it and we are looking at mitigations
(the algorithm might be a little too aggressive for sending into the public
Internet).

Tom


> Cheers
>     Toerless
>
> On Sat, Aug 07, 2021 at 06:37:52PM +0300, Töma Gavrichenkov wrote:
> > Peace,
> >
> > On Sat, Aug 7, 2021, 6:19 PM Toerless Eckert <tte@cs.fau.de> wrote:
> >
> > > Do our RFCs say or imply anything about whether or not hosts can change
> > > the IPv6 flow label field of a single flow during the lifetime
> > > of a flow (MUST, SHOULD, MAY, ... MAY NOT, SHOULD NOT, MUST NOT)
> > >
> >
> > Well, it is, of course, sort of implied that the flow label is attached
> to
> > the particular flow.
> >
> > As per normative references, RFC 6437 goes (underscores are mine):
> >
> > > It is therefore RECOMMENDED
> > > that source hosts support the flow label by setting the flow label
> > > field for _all_packets_of_a_given_flow_ to the _same_value_ chosen from
> > > an approximation to a discrete uniform distribution.
> >
> > --
> > Töma
> >
> > >
>
> --
> ---
> tte@cs.fau.de
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>