Re: Never fragment: getting PMTU info transmitted reliably

[Brian E Carpenter <[e-mail]>]

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.

   Brian

> 
> It's about how fresh the (disk read) caches on the servers are, what content
> is being streamed, and other things that have nothing to do with the
> packets themselves.
> 
> Architecturally with IPv6, if you have an entire /64 (or more) to play with
> and you can statelessly forward packets at wire speed,  then there are
> other interesting off-path choices one can do.  (For instance, assign
> new server/128 for each client connection, and then when the connection
> arrives, dynamically map it to a particular server.  This pushes the state
> storage from layer-4 to the neighbour cache, which might not be a win)
> 
> So I seriously question whether any of this matters to server farms.
> 
>     > I am strongly against breaking the flow label just at the time when
>     > the major o/s are starting to set it correctly.
> 
> :-)
> 
>     > I'm all for fixing the fragmentation problem;
>     > draft-ietf-intarea-frag-fragile
>     > exists for a reason. But not by breaking something else.
> 
> My quick read says that it looks great to me.
> 
> Again, I don't really think that using the flow label to seed PLPMTUD
> is much of a win, but if it did provide something useful, I think it could be
> done without too much harm.
> 
> To reiterate: I don't think the benefit is high enough to warrant the
>    risk, despite the fact that I don't think the risk is as high as you
>    are suggesting.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>