Dear Pascal, Many thanks for your feedbacks!
Best, Giorgos > On Jun 21, 2019, at 17:05, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello Georgios > > Many thanks for your review, please see below: > >> In Figure 1, a packet forwarded by node A to node B is cut into nine >> fragments, numbered 1 to 9. Each fragment is represented by the '#' >> symbol. Node A has sent fragments 1, 2, 3, 5, 6 to node B. Node B >> has received fragments 1, 2, 3, 6 from node A. Fragment 5 is still >> being transmitted at the link layer from node A to node B. >> >> >> [GP] Isn’t it more straightforward to consider 1, 2, 3 and 4 been sent, >> 5 is still being transmitted, while, 6, 7, 8 and 9 to be transmitted? >> Otherwise, there are concerns, why fragments 5 and 6 before 4? >> Fragment 4 was transmitted earlier and was not successful? > > I guess it's an implementation thing. It is possible that a retry is queued > at the top of the xmit queue and that the next fragment is already there now. > The first fragment must be successfully transmitted first, because the next > hop would not know what to do with a non-first fragment arriving first. I > added a word on that in the limitations. > All the other fragments could be sent in any order. I see the scenario. Thx. > >> A fragmentation header is added to each fragment; it indicates what >> portion of the packet that fragment corresponds to. Section 5.3 of >> [RFC4944] defines the format of the header for the first and >> subsequent fragments. All fragments are tagged with a 16-bit >> "datagram_tag", used to identify which packet each fragment belongs >> to. Each fragment can be uniquely identified by the source and >> destination link-layer addresses of the frame that carries it, and >> the datagram_tag. >> >> [GP] This is not entirely true, right? This is yet, another limitation >> of RFC 4944. There is no guarantee that two different source nodes >> (A and B) may pick up the same “datagram_tag”, and send their >> fragments to C, and then C when sending to D, will have two fragments >> with same tags, and the same source and destination link-layer addresses. > > But then with RFC 4944 there is no relaying fragment so there is no point in > RFC 4944 to consider that case. True! > The rule above is correct and the reason we swap the tag in node C is to keep > it true so we do not end up in the situation that you describe. Correct, thx. >> >> VRB overcomes the limits listed in Section 2. Nodes don't >> >> [GP] don’t —> do not > > done > > >> No Per-Fragment Routing: All subsequent fragments follow the same >> sequence of hops from the source to the destination node as >> fragment 1. >> >> [GP] Maybe a clarification could be added in the last limit, i.e., that >> only the fragment 1 has the sources and destination addresses. > > Proposed to change to > " > No Per-Fragment Routing: All subsequent fragments follow the same > sequence of hops from the source to the destination node as the > first fragment, because the IP header is required to route the > fragment and is only present in the first fragment. A side effect > is that the first fragment must always be forwarded first. > “ Seems good to me. > >> 4. Security Considerations >> >> An attacker can perform a DoS attack on a node implementing VRB by >> >> [GP] DoS is not defined earlier > > Added > > > Again, many thanks Georgios. > > All the best, > > Pascal > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
