On 08-Aug-21 07:41, Tom Herbert wrote: > > > On Sat, Aug 7, 2021, 10:55 AM Toerless Eckert <tte@xxxxxxxxx <mailto:tte@xxxxxxxxx>> 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" I can't speak for what the IETF thought when it reached consensus on that statement. I can speak for what I thought when it was drafted: we didn't know enough about how the flow label would work in practice to tighten the definition of "flow". In the context of unicast destinations, that isn't catastrophic for on-path load balancing. It may be catastrophic for server load balancing, however. Or taking a different view, it may be desirable for server load balancing to use the same flow label for different transport associations that happen to be part of the same application layer transaction. (Hence the need for an API as Robert Raszuk noted on another sub-thread.) What I don't like is Linux deciding this for me. It may be convenient in some DC scenarios, and highly inconvenient/damaging in other scenarios. It clearly needs to be a settable option per transport session. Brian > 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@xxxxxxxxx <mailto:tte@xxxxxxxxx>> 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@xxxxxxxxx <mailto:tte@xxxxxxxxx> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx <mailto:ipv6@xxxxxxxx> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> > -------------------------------------------------------------------- >
