Peace, On Sat, Aug 7, 2021 at 11:31 PM Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> 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
