Hello Pascal, Am Mi., 6. Feb. 2019 um 16:36 Uhr schrieb Pascal Thubert (pthubert) < [email protected]>:
> 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. 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. > All the best, > > > > Pascal > Best regards, Martine > > > *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
