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

[Töma Gavrichenkov <[e-mail]>]

Peace,

On Sat, Aug 7, 2021 at 11:31 PM Michael Tuexen
<[e-mail]> 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