On Sat, Aug 7, 2021 at 1:30 PM Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote: > > > On 7. Aug 2021, at 21:41, Tom Herbert <tom@xxxxxxxxxxxxxxx> wrote: > > > > > > > > On Sat, Aug 7, 2021, 10:55 AM Toerless Eckert <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" > > > > 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. > 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. > Right. There's also QUIC where a NAT may evict a UDP 4-tuple state and later instantiate a new tuple for the QUIC connection with different port numbers. QUIC is designed to survive this since the UDP port numbers are part of its connection tuple, but changing the UDP port numbers mid-flow could change ECMP routing such that an anycast endpoint could become unreachable. In reality, it's not that flow label modulation or NAT break anycast, it's that anycast is inherently broken since it makes assumptions that are true only most of the time. Tom > Best regards > Michael > > > > 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> 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 > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@xxxxxxxx > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >
