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

[Tom Herbert <[e-mail]>]

On Thu, Dec 3, 2020 at 12:42 PM Fernando Gont <[e-mail]> wrote:
>
> On 3/12/20 14:30, Tom Herbert wrote:
> [....]
> >
> > There are two apropos statements in RFC6437:
> >
> > "There is no way to verify whether a flow label has been modified en
> > route or whether it belongs to a uniform distribution.  Therefore, no
> > Internet-wide mechanism can depend mathematically on unmodified and
> > uniformly distributed flow labels; they have a "best effort" quality."
> >
> > "From an upper-layer viewpoint, a flow could consist of all packets in
> > one direction of a specific transport connection or media stream.
> > However, a flow is not necessarily 1:1 mapped to a transport
> > connection."
> >
> > So building a load balancer, or any other intermediate network device,
> > that *depends* on the flow label to be consistent for the life of a
> > transport connection and 1:1 mapped to a transport connection is
> > contrary to this guidance.
>
> We don't need 1:1. We just need 1:N where N is how flows would be
> aggregated/grouped for the purpose of load-sharing.
>
>
>
> > The ship has already sailed on this in
> > deployment, and even if the protocol requirements were to be
> > sufficiently tightened that would take years to reach full effect and
> > that would preclude other use cases where modifying the flow label is
> > useful. If a stable 1:1 mapped identifier for transport ports is
> > needed in the network layer, it might make sense to create a new HBH
> > option for that.
>
> The above said, I would probably agree that if havinga non-stable FL
> breaks something, whatever it breaks is probably already broken, since

Fernando,

Not to belabor the point, but stable flow labels were never
guaranteed, so if some node has a problem with non-stable flow labels
then they are themselves broken because they are making an incorrect
assumption.

> there's not even a checksum to try to detect whether the IPv6 header has
> been corrupted.
>
Neither is there checksum that covers the UDP port numbers when UDP
checksum is zero. A "stable" identifier that the network can use to
conclusively identify transport flows does not generally exist.

>
>
> > Personally, if I were building a load balancer I'd
> > use neither the flow label nor transport ports for entropy, I'd look
> > at using the destination address since 128 bits allows plenty of bits
> > of entropy, it's consistent per transport flow and always set in an
> Problem is that if you have two systems that need a lot of banswitdth
> (e.g., they are transferring file via several TCP connections)< you
> wouldn't be able to load-share them -- since the result of the hash
> would be the sme for all TCP connections....
>
Use a different IP address per connection. This idea has already been
brought up in the context of security since it could make it harder
for malicious network observers to correlate different flows as having
the same source, and the same principle could be applied to load
balancers where each of the backends is assigned a block of IP
addresses (like a /64). After that, it's a matter of getting clients
to use some random address from the load balancer blocks (instead of
always using one). IIRC, Brian Carpenter once suggested that we really
didn't need port numbers any more since they could be part of the
address-- for load balancers there might be some merit to that.

 Tom

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>