Re: Non-Last Small IPv6 Fragments

[Warren Kumari <[e-mail]>]

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

:-)
W

>
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> 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