Hi Richard > In route over the L2 source changes at each hop. The datagram tag is > associated to the source MAC and only valid (and unique) for that source > MAC. > > Upon a first fragment: > ---------------------- > [...] > > Upon next fragments (that are not first fragments) > -------------------------------------------------- > [...] > > Upon fr-acks: > ---------- > - lookup (MAC_nxt, DT_nxt) to get (MAC_prv, DT_prv) > - If not found drop. > - else swap mac and tag and forward, as before > - if the bitmap is acks all (could change the draft to make it all ones) > or errors (all zeroes) cleanup resource > >You have to be careful about cleaning up just because you >see a complete ack. Transmission is unreliable in both >directions. If an intermediate node deletes the record and >the source fails to get the complete ack, the source will >start over from the beginning, even though the destination >already has the packet. And with the label/datagram_tag >swapping, the destination has no way of knowing that the >retransmission is a copy of a packet it has already received.
Say that an ack(all) or and ack (0 == error) cleans up the states down to a point where it gets lost midway. If the retried fragment is not the first fragment, the first node that cannot forward that fragment because it has its states cleanup has to ack (0 == error), effectively cleaning the rest of the way between the source and itself. A node that exhausts retries on a fragment can also to that. One side question is whether the packet that ends up in ack(0 == error) should be retried at the source, and I think not. So the problem is limited to loosing the ack that acks the first fragment. The source will retry it and establish a new path, where the packet will be resent. If the lost ack was an ack(all), that means that all the fragments were acked in a single shot. The packet will be duplicated. One way of avoiding duplication is to drop a packet when the first fragment is lost. Another is to have intermediate acks that force to ack the first fragment before they are all sent. It appears that the frag draft would benefit from a way for the source to clean up all on the way forward like the ack(0) does on the way back. I'll look into it. > It appears that with the local operation above any node > can play the game or not without knowledge that the peers > also do. In other words, we could reassemble along the > way and only nodes that wish/know_how_to skip the process > would do so. > >I still think that there needs to be a way to distinguish >between an intermittent problem, where just resending a >dropped fragment is enough, and a broken route. This gets >a lot harder if an intermediate node might reassemble the >packet. > The whole idea is that a path is broken but that routing should find a new one. If you reassemble at midway, then the packet has progressed forward and the router that now owns the packet is the new source for a fragmentation process. If the label path gets broken between it and the next fragmentation endpoint, the router is entitled to find a new path. If it cannot, it is up to routing to fix that. RPL attempts to maintain DAGs to enable multiple forwarding solutions and limit that risk. My question to the group is whether this frag forwarding process should be described in the frag draft. The reason why we might need to do so is the need to ack(0 == error) en route when the label path is broken or the retries are exhausted. The need to do this comes from the label switching trick and does not make sense otherwise. What do you think? Cheers, Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
