Re: Non-Last Small IPv6 Fragments

> On 16 Jan 2019, at 16:11, Warren Kumari <warren@kumari.net> wrote:
> 
> 
> 
>> On Wed, Jan 16, 2019 at 2:52 AM Fernando Gont <fgont@si6networks.com> 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...
> 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. 

A splendid idea indeed. 
Of course you could also take the topmost bit of the payload field and encode the 8 bits required in a vector of packets. I suggest using a magic cookie first. E.g the string “MTU”, rot-13 encoded in morse. This way you should be able to signal the MTU in less than a hundred packets. 

Ole

> 
> 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...
> 
> :-)
> W
>> 
>> 
>> 
>> -- 
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
>> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------