Re: Non-Last Small IPv6 Fragments

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

On 2019-01-17 04:11, Warren Kumari wrote:
> On Wed, Jan 16, 2019 at 2:52 AM Fernando Gont <[e-mail]> wrote:
> 
>> On 15/1/19 22:02, Brian E Carpenter wrote:
>>> For my comment, search for "Aaargh"
>>
>> :-) -- I was catching up with email, and read them in sequence. --
>> thanks for the note, I *expected* it :-)
>>
>>
>>
>>>>     > [Silly Idea #2]
>>>>     > Separate, even sillier idea: everyone converges on using 16 bits
>> of
>>>>     > the flow ID to encode the lowest MTU encountered along the path.
>> Here
>>>>     > again, TCP MSS clamping style behaviour would be applied to this
>>>>
>>>>
>>>> https://media.giphy.com/media/3o6ZthnDqxfAOFIhdC/giphy.gif
>>>> Because there are deployed systems already, I don't think that this can
>> be deployed **and fully relied upon**, but Ido think that it might actually
>> be really useful. If the first 2 bits of the flow label are '11' or '10' or
>> something, then it could mean that the next N (13?) bits of the flow label
>> contain the minimum MTU along the path.
>>>
>>> Aaargh. That's a gross violation of the standard for the flow label.
>> Short form: you can't use the flow label for signaling. Long form: RFC6436,
>> RFC6437, plus RFC6294 for a menagerie of other terrible ways to abuse the
>> flow label.
>>
>> Or, put another way: if we were to use the FL for this, it would screw
>> up the currently-intended use.
>>
> 
> Yup, I had actually read those the above, but it was a while back...
> 
> I'm not really sure it does screw up the intended use -- the FL is 20 bits.
> If we were to do something like Erik had proposed, and we wanted to be able
> 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...

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?

> If we only wanted to signal full granularity between 1500 and 1280, and
> then require that any MTU between 1500 and 9K falls into one of 36 buckets,
> we could reserve one byte to do so (1500-1280=220. 256-220=36).
> 
> This likely is still a horrible, no good idea, but it does at least make
> the MTU available to things looking at the L3 header only, and doesn't
> require routers to have to dig into extension headers.
> 
> Whatever the case, when we finally design IP-NG-NG, let's set aside 512bits
> (at least) to be "reserved for future abuse" :-P Or, perhaps, every bit
> should be fully cast in stone (with no room for extensions) so that they
> don't become attractive nuisances for ugly hacks...

I hope that by then we will have found a better approach to flexibility
and extensibility that allows for interfering middleboxes from the start.
But that discussion is definitely out of scope for the "IPv6 Maintenance" WG ;-)

    Brian

> 
> :-)
> W
> 
>>
>>
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>>
>