Re: Never fragment: getting PMTU info transmitted reliably

[Brian E Carpenter <[e-mail]>]

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.

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