IETF Logo Mail Archive

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

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 09 August 2021 08:01 UTC

Return-Path: <vasilenko.eduard@huawei.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 6FF483A07D8; Mon, 9 Aug 2021 01:01:25 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 TLcbH9W-Gc4K; Mon, 9 Aug 2021 01:01:20 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950AA3A07D6; Mon, 9 Aug 2021 01:01:20 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GjpRk2KByz6D93y; Mon, 9 Aug 2021 16:00:50 +0800 (CST)
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Mon, 9 Aug 2021 10:01:16 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 9 Aug 2021 11:01:16 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Mon, 9 Aug 2021 11:01:16 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Töma Gavrichenkov <ximaera@gmail.com>, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
CC: Tom Herbert <tom@herbertland.com>, 6man WG <ipv6@ietf.org>, IETF discussion list <ietf@ietf.org>
Subject: RE: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
Thread-Topic: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?
Thread-Index: AdeITEcEgFJ2cblRTf2jVtlvbXQCSf//1HuAgAAKBoCABbMDAIAAHJEAgADFrgCAAAXCAIAAJhUAgAAd7wCAAA2xgIAAG/iA//2WXyA=
Date: Mon, 09 Aug 2021 08:01:16 +0000
Message-ID: <c36e468fa3c647b5829515adfabf3fcc@huawei.com>
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> <CALZ3u+Z8AOwjBY_JHSctRXtpQ=x63d=oATfqrkPfMduWujbuvw@mail.gmail.com>
In-Reply-To: <CALZ3u+Z8AOwjBY_JHSctRXtpQ=x63d=oATfqrkPfMduWujbuvw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.207.136]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8gA8r--OxxOmRXGnBbOxNXEy4mM>
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 08:01:26 -0000

+1

-----Original Message-----
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Töma Gavrichenkov
Sent: Sunday, August 8, 2021 1:10 AM
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: Tom Herbert <tom@herbertland.com>; 6man WG <ipv6@ietf.org>; IETF discussion list <ietf@ietf.org>
Subject: Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

Peace,

On Sat, Aug 7, 2021 at 11:31 PM Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> I think it comes down to the question of what a flow is...
>
> Some might consider a TCP connection being a single a flow, some seems 
> to think that a TCP connection consists of multiple flows, especially a new flow being started on a timer based retransmission.

The TCP connection, or a QUIC connection, or an SCTP connection, or whatever there is...
The flow is just not the _concept_ of the layer where all of those types of connections keep grazing.

The flow is the _application_concept_. It's entirely up to the application whether the latter considers certain requests, encapsulated in IPv6 packets, to be a part of the same flow (and these thus should be all treated by the network, transport-wise, in a similar fashion), or not.

Due to the incredibly long IPv6 deployment timeline, this concept has sort of slipped away from the protocol implementors.  Therefore, the perfect scenario where the _application_ itself decides whether it wants to keep the flow label on the transport connection or not practically vanished in implementations.  There just were no requests for the control over the flow label function to be available to the application layer, because no one cared about the performance of applications over IPv6...

...because no one really have had any real demands for the IPv6 performance, as it has, quite unfortunately, become a fine practice to just switch off IPv6 once there seem to be any performance issues with the network.

Either it's the application which is the entity controlling the flow label function, or the flow label concept should be abandoned, here's the gambit.

--
Töma

v2.23.0 | Report a Bug | By Email