Re: [Softwires] MAP draft 11 question on fragment ID space reduction

[Joe Touch <[e-mail]>]

On 10/14/2014 2:58 AM, Ole Troan wrote:
...
> splitting the fragment id space so that there is only a single bit 
> per CPE sounds like a corner case that should be disallowed. I don't
> know if we have the knowledge to be able to specify exactly how much
> of the fragment id space is safe to split up though.is it 4, 6, or 8
> bits?

As per RFC 6864, the IPv4 ID space is small and use of that space needs
to consider the number of current IP packets being reassembled, i.e.,
the reordering likely to occur.

It might be safe to use a space one bit larger than the amount of
reordering, but I'd prefer two.

So the key question is:

	- how much fragment reordering to you expect *within*
	a given IP address pair/transport tuple?

I don't know the answer to that, but log2(reordering) + 2 ought to be a
lower bound on the space that might overlap.

I.e., I doubt you should ever allow 1-2 bits. I would expect a minimum
of 4 bits but the appropriate answer depends on the reordering you're
trying to protect against.

NOTE: I would strongly encourage an encapsulation that includes its own
checksum to protect against incorrect reassembly (if that's not already
included; I haven't checked the draft).

Joe