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.
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. All the best, Pascal From: 6lo <[email protected]> On Behalf Of Martine Lenders Sent: mercredi 6 février 2019 15:49 To: [email protected] Subject: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries? Hi, I'm currently in the process of implementing first prototypes of both minimal fragment forwarding [1] and fragment recovery [2] for RIOT [3]. However, I'm unsure how I can determine when it is safe to remove a VRB entry at least for the minimal forwarding case (even for a successfully transmitted datagram). As far as I have seen not even the original VRB draft [4] mentions a strategy for that. For the success case I could of course just count the bytes of the fragments and remove the VRB entry once I reach the datagram size, however this does not account for possibly received duplicates (unless I keep track of at least the intervals of all received fragments which of course costs more memory). The failure case is easier, since I could just use the timeout used in the original 6Lo fragmentation, but using this for the success case as an alternative to my proposal above might lead to a congestion of the VRB. Are there any other strategies I might have missed? Kind regards, Martine Lenders [1] https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/ [2] https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ [3] https://github.com/RIOT-OS/RIOT [4] https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
