On Friday, 11 January 2019 18:09 Peter Oskolkov wrote:
> On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <twint...@iol.unh.edu> wrote:
> > Thanks for the clarification. I'm thinking about creating a draft
> > to say no fragments less then 640 unless it's the last fragment.
> > Does that work for your code going forward?
>
> I will prepare a patchset to convert IPv6 defrag queue to rbtree+list,
> similarly to how IPv4 defrag queue currently works. Just in case it
> is decided to go this route. I don't think having an
> arbitrary/non-standard size cap (640) is a good approach.
It's not completely arbitrary. The idea is that two most obvious
fragment sizing strategies are
(a) use maximum possible size for all except last, then the rest
(b) calculate minimum required fragment count and use (almost) the
same size for all of them
Both strategies create non-last fragments of size at least 1280 / 2.
But I agree that using the same data structure and algorithm as for
IPv4 is more future proof.
Michal Kubecek
