Re: Never fragment: getting PMTU info transmitted reliably

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

Hi Erik,

On 2019-01-17 16:17, Erik Kline wrote:
> On Wed, 16 Jan 2019 at 18:56, Brian E Carpenter
> <[e-mail]> wrote:
>>
>> On 2019-01-17 15:39, Michael Richardson wrote:
>>>
>>> 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"?
>>>
>>> Based upon my reading of the netflix blogs, they have experiemented
>>> extensively with the load sharing, and they really don't care about
>>> flow-labels in their decision process. (Of course, because IPv4 has
>>> no such things)
>>
>> Indeed, but that's exactly why we brought in a load sharing expert
>> to help us with RFC7098. And there are residual problems even in the
>> ideal world where the flow label is perfect. We played with some ideas
>> in https://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing
>> but it didn't really go anywhere. In a nutshell, what's really needed
>> is a bidirectional session ID, not a unidirectional flow ID. And
>> that's not a layer 3 concept.
> 
> The potential utility of an operational convention that treats the
> flowlabel akin to the TCP MSS field would seem to me to be much higher
> than trying to help internet hyper giants with their load balancing.
> All the more so if the load balancing is better solved with info from
> layers above L3 (going to need to load balance on QUIC connection IDs
> now, too).

The flow label is a proxy for the information above layer 3. As we
know, that information is unavailable in many cases, because of
encryption, intervening extension headers, or fragmentation.

Certainly a QUIC sender must set the flow label; RFC6437 is agnostic
about the transport layer. It says so explicitly, written years
before QUIC was invented:

"  Additionally, if classifiers depend only on IP-layer headers, later
   introduction of alternative transport-layer protocols will be easier."

> (Writing a patch to the Linux kernel to stamp the MTU of the outgoing
> interface into the flow label doesn't look like it's too hard.)

No, but it would violate the relevant IETF standards.

   Brian