Re: Never fragment: getting PMTU info transmitted reliably

[Erik Kline <[e-mail]>]

On Wed, 16 Jan 2019 at 18:56, Brian E Carpenter
<[e-mail]> wrote:
>
> On 2019-01-17 15:39, Michael Richardson wrote:
> >
> > Brian E Carpenter <[e-mail]> wrote:
> >     > On 2019-01-17 13:12, Joel M. Halpern wrote:
> >     >> Just to clarify one aspect of the way entropy in path selection, I want
> >     >> to point out a complication.
> >     >>
> >     >> It is not anywhere near enough to have as much entropy data as the
> >     >> number of choices.  The problem is that you need enough randomness so
> >     >> that you can expect a good distribution of flows.  And that even the
> >     >> smaller number of larger flows will likely get distributed across the
> >     >> choices.    Reducing the amount of available entropy can be quite
> >     >> problematic.
> >
> >     > Right. And for the server farm case, I don't think it's science fiction
> >     > these days to think about hundreds or thousands of servers. Also, if the
> >     > load sharing algorithm attempts to ensure that a given server has only
> >     > one big job at a time, then a high collision rate in the hash can
> >     > defeat it. A form of the birthday paradox applies: not "what is the
> >     > chance of a clash per flow" but "what is the chance that out of a
> >     > thousand servers, one of them gets two big jobs at the same time"?
> >
> > Based upon my reading of the netflix blogs, they have experiemented
> > extensively with the load sharing, and they really don't care about
> > flow-labels in their decision process. (Of course, because IPv4 has
> > no such things)
>
> Indeed, but that's exactly why we brought in a load sharing expert
> to help us with RFC7098. And there are residual problems even in the
> ideal world where the flow label is perfect. We played with some ideas
> in https://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing
> but it didn't really go anywhere. In a nutshell, what's really needed
> is a bidirectional session ID, not a unidirectional flow ID. And
> that's not a layer 3 concept.

The potential utility of an operational convention that treats the
flowlabel akin to the TCP MSS field would seem to me to be much higher
than trying to help internet hyper giants with their load balancing.
All the more so if the load balancing is better solved with info from
layers above L3 (going to need to load balance on QUIC connection IDs
now, too).

(Writing a patch to the Linux kernel to stamp the MTU of the outgoing
interface into the flow label doesn't look like it's too hard.)