Re: Never fragment: getting PMTU info transmitted reliably

[Mark Smith <[e-mail]>]

On Thu, 17 Jan 2019 at 11:30, 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.
> >

<snip>

> I am strongly against breaking the flow label just at the time when
> the major o/s are starting to set it correctly.
>

It would be being set quite widely now.

OS X and Linux (courtesy of Tom Herbert) have set it by default for a
number of years.

The Windows 10 Creator Update released in July of 2017 started setting it

https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/

And Microsoft have said that as of June last year Windows 10 was on
700 million PCs.

https://windowsreport.com/windows-10-market-share-2018/

So there would have to be be 100s of millions of devices now setting
the flow label per RFC 6437.

> I'm all for fixing the fragmentation problem; draft-ietf-intarea-frag-fragile
> exists for a reason. But not by breaking something else.
>
>    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
> --------------------------------------------------------------------