RE: Never fragment: getting PMTU info transmitted reliably

["Lubashev, Igor" <[e-mail]>]

There is a lot of complexity in injecting entropy into IP addresses. As long as using a 4-tupple for TCP and UDP traffic, 2-tupple+SPI for IPSec, 2-tupple+Key for GRE, etc. "just works", there is little incentive to deploy complex solutions that involve DNS, neighbour caches, etc. The hope for new protocols on top of ipv6 is the flow label, because it is so simple to use right by everyone: the sender, the receiver, and the middle boxes.

- Igor

-----Original Message-----
From: Tom Herbert [[e-mail]]
Received: Wednesday, 16 Jan 2019, 11:36PM
To: Mark Smith [[e-mail]]
CC: Michael Richardson [[e-mail]]; IPv6 List [[e-mail]]
Subject: Re: Never fragment: getting PMTU info transmitted reliably

On Wed, Jan 16, 2019 at 7:28 PM Mark Smith <[e-mail]> wrote:
>
> On Thu, 17 Jan 2019 at 13:57, 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.
> >
>
> I think really what you want is an anycast IPv6 service address in DNS
> for the load balanced service that the client uses to establish the
> initial transport layer connection, and then a method to announce to
> the client and then hand off that session to the unicast address of
> the server actually handling the session. That would make the load
> balancer with the anycast service address more of a session broker
> rather than something that is inline with all the sessions' traffic.
>
Mark,

Alternatively, a new record type could be added to DNS that returns
blocks of IPv6 address (could be called BBBB records). The BBBB record
would be something like a base IPv6 address and an extent. Given the
enormous size IPv6 addresses, a single record could contain billions
of addresses for a service. The client just needs to pick address in
the blaock at random, and load balancing to backend servers is
accomplished by routing to back end servers solely based on
destination address (each backend server serves some portion of the
address block). No need for VIPs, anycast, DPI into the transport
layer, or stateful load balancing. This also has the advantage of
introducing a lot more bits of entropy for other load balancing
techniques like ECMP (using a different IPv6 source IP address for
every connection would have a similar effect).

Tom


> Multipath TCP would fit the bill, and I assume the multipath
> extensions for QUIC will too.
>
> >    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 =-
> > >
> > >
> > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------