Re: [tcpm] [v6ops] Flow Label Load Balancing

On Tue, Nov 24, 2020 at 12:07 PM Fernando Gont <fernando@gont.com.ar> wrote:
>
> On 19/11/20 07:48, Alexander Azimov wrote:
> > Dear colleagues,
> >
> > I have added in the cc both v6op and tcpm for a reason and let me
> > explain why.
> >
> > It's clear that we are moving forward with load balancing that uses flow
> > label (FL). And the pressure will increase with SRv6 adoption. But at
> > the moment wide adoption of FL-based load-balancing may create
> > significant issues for TCP Anycast services.
> >
> > RFC6437 suggests putting hash from 5-tuple into FL value. And as far as
> > I know, there is no document that updates this behavior. This
> > description is perfectly fine, but what is implemented in the Linux
> > kernel is different: FL is carrying hash from 5-tuple with an additional
> > seed, and this seed is randomly changed after each RTO/SYN_RTO event.
>
> Changing the FL upon RTO is a bug.
>
> I guess/assume that when you say SYN-RTO, you really mean "user
> timeout", rather than RTO. If you don't, then that's also a bug.
> If you do, I fail to understand what's the reason for wanting the FL to
> change in that case, because as a result of port randomization, it 0s
> unlikely that the same four-tuple is employed for the next connection retry.
>
>
> > Here are related patches:
> >
> >   * https://lore.kernel.org/netdev/alpine.DEB.2.02.1407012100290.20628@tomh.mtv.corp.google.com/
> >   * https://lore.kernel.org/netdev/1438124526-2129341-1-git-send-email-tom@herbertland.com/
> >   * https://lore.kernel.org/netdev/20160928020337.3057238-1-brakmo@fb.com/
> >
> >
> > This is a great thing by the way because in the data center
> > environment with multiple equal paths it gives a way to have
> > pseudo-multipath TCP which jumps between paths in case of an outage.
> > There might be interest to writedown an informational document for this.
>
> That's a bad idea, since specs-wise the Flow-Label is not guaranteed to
> remain unchanged from source to destination. If you want to ahve
> multiple paths, then you should implement that in routing.
>
>
>
> > I wonder what you think is a proper solution:
> >
> >   * Making FL related RTO change as knob instead of default behavior;
> >   * Adding negotiation behavior in TCP;
> >   * Something else?
>
> Just make the FL a function of the connection "identifier". And keeo it
> constant for the lifetime of that conenction.

Fernando,

Modulating the flow label is a means to affect the routing of packets
through the network that uses flow labels as input to the ECMP hash.
The basic idea is that the flow label associated with a connection is
randomly changed when the stack observes that the connection is
failing (e.g. and an RTO). There is nothing in the specs that prevents
this since the source is at liberty to set the flow label as it sees
fit. The feature is useful in large datacenter networks, like
pparently Facebook where the patches originate, since information
discerned by TCP can opportunistically be applied to route selection.
The practical issue is that there are stateful devices like firewalls
that require consistent routing in the network in which case changing
the flow label can confuse them. As I mentioned, the original intent
was that the flow label randomization feature should be opt-in instead
of on by default.

Tom
>
> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops