Never fragment: getting PMTU info transmitted reliably

[Michael Richardson <[e-mail]>]

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