Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Martine

Fragments follow a same path, but this is not a guarantee that they will not be mis-ordered. So whatever you do, it should not be immediate but done upon a time out because once the VRB is gone, packets are dropped. Note that if the first packet is delayed, then minimal-fragment is in trouble.

That was clear ;-). However, I'm not sure it necessarily is in trouble. At least in our (classic) reassembly buffer implementation, enough of the original fragments data is still there (to detect overlaps), so that a refragmentation for the first x fragments is still possible, once the first fragment arrives and the reassembly buffer entry can be transformed into a VRB entry.

Well, then it’s hard to differentiate an early fragment from a late fragment, and there‘s possibly an additional risk of DoS attack compared to a packet where the IP header allows some checking.

For fragment-recovery-01 there is text in 7.3 about cleaning the VRB, basically an ACK that indicates a reset of a complete reception (all 0 or all 1) triggers a short timer to destroy the VRB. This is done in case the ack is lost on the rest of the way back and the last flow is retried. There is also text at the end of section 6 that indicates that a reset by the sender may not have an rfrag-ack request bit set. In that case, the same operation as if the RFRAG ack was received applies. I could add a word on that.

Ok, but for the sake of comparison I also need the minimal approach.

Minimal makes intermediate nodes virtual endpoints.
So I expect that the best you can do is behave like an end point and clear your state when 1) you have forwarded a complete virtual datagram and 2) upon time out in case of an error.
If you recreate a VRB for a late packet then yes, I’d protect case 1) that with a small time out to cover that situation.

All the best,

Pascal