Re: Never fragment: getting PMTU info transmitted reliably

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.

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 <brian.e.carpenter@gmail.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 