Re: Never fragment: getting PMTU info transmitted reliably

[Michael Richardson <[e-mail]>]

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)

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 =-