Re: Never fragment: getting PMTU info transmitted reliably

[Tom Herbert <[e-mail]>]

On Wed, Jan 16, 2019 at 4:30 PM 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"?
>
> 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.
>
Agreed. Turning up flow labels was one of few things we were able to
do immediately at scale and doesn't seem to have caused problems.
Unfortunately, there aren't any available reserved bits in the IP
header and no bits that could easily be purposed (even if there were
it would a major discussion about what use cases warrant allocation of
bits in the primary IP header). IPv6 is extensible by virtue of
extension headers, that is where things like this belong.

Tom

>    Brian
>
> >
> > Yours,
> > Joel
> >
> > On 1/16/19 6:36 PM, Michael Richardson wrote:
> >>
> >> Warren writes about putting MTU info into flow Label:
> >>      >> to signal up to a 9K MTU, we would need 13bits (LN(9K-1280)/LN(2) =
> >>      >> 12.9).
> >>      >> 20 - 13 gives 7 bits (128) for the hash entropy. "7 bits of entropy,
> >>      >> evenly distributed, should be enough for anyone", he said, hoping
> >>      >> no-one points at
> >>      >> the obvious correlation to 640K of RAM...
> >>
> >> Brian E Carpenter <[e-mail]> wrote:
> >>      > I guess it all depends what you expect from the entropy. 20 bits gives
> >>      > you a 1-in-a-million chance of a clash. 7 bits gives you a 1-in-128 chance
> >>      > of a clash. This probably doesn't matter for a simple ECMP or LAG kind
> >>      > of load sharing, but who's to say it doesn't matter for some more
> >>      > fancy kind of sharing across a large array of servers?
> >>
> >> You'd have to have more than 128 servers and/or paths.
> >> Maybe one of our SPRING people in this WG can tell us if that's a real
> >> problem today.  Obviously, we can't guess if it will be bad in the future,
> >> but if it's a problem today, then we can know that immediately.
> >>
> >> Now when I pushed for draft-ietf-6man-rfc6434-bis-09 and RFC8200 to say
> >> that PLMTUD to be made MUST, I got various push backs that amounted to:
> >>    1) we don't have enough evidence yet.
> >>    2) it doesn't work for UDP and other traffic.
> >>
> >> (1) turned out to be a real issue. I thought that some of the big players
> >>      could easily get, or already would have, that kind of evidence.
> >>      (Linux does not ship with PLPMTUD on by default.  If you want it, btw,
> >>      sysctl -w net.ipv4.tcp_mtu_probing=2.  Yes. ipv4. It affects both)
> >>      Turns out I was told that they always set their TCP segment size such that
> >>      they likely will never fragment for v4 or v6, because due to hardware
> >>      Transit Offload, the cost of missing a tx-op exceeds the benefit of
> >>      making the packet slightly bigger.  I suspect that this is true in
> >>      general to UDP and QUIC traffic too.
> >>      I imagine a next generation 10G NICs might offer QUIC offload, including
> >>      doing the crypto.  That's what I'd be coding if I worked in that space.
> >>
> >> 2) I will admit that I personally don't care that much about UDP traffic,
> >>     except in that it lets me run IPsec through NAT44s.   I know that I use
> >>     QUIC and WebRTC regularly, and that corporate enterprise users gets
> >>     screwed by lack of UDP regularly.
> >>
> >> So I think question is: is there really a problem that needs to be solved?
> >> Maybe I will have to back and read the beginning of this thread again to
> >> recall what the issue was.   Does this belong in SPUD?
> >>
> >> I wish that SCTP had flown higher...
> >>
> >> --
> >> 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
> --------------------------------------------------------------------