Yatch, Thanks for your review. I have taken all of your suggestions into account, and plan to publish -01 by the cut-off date.
The plan is to have a "fragmentation DT" section at the 6lo meeting where this draft will be presented. Thomas On Tue, Feb 27, 2018 at 7:20 PM, Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> wrote: > Hi all, > > I'd like to share my comments on draft-watteyne-6lo-minimal- > fragment-00.txt. > > LLN Minimal Fragment Forwarding > https://www.ietf.org/id/draft-watteyne-6lo-minimal-fragment-00.txt > > I have four comments: > > [1] > > 1. Overview of 6LoWPAN Fragmentation > > (snip) > > In Figure 1, 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. > > It'd be nice to explain the figure a little bit more, the symbol of '#' and > numbers above the boxes, like this: > > In Figure 1, a packet forwarded by node A to node B is cut into > nine fragments, from fragment 1 to fragment 9. Each of them is > represented with '#' 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. > > [2] > > 3. Virtual Reassembly Buffer (VRB) Implementation > > (snip) > > next hop to send this fragment to. It then creates an entry in the > > VRB table which contains 4 fields: (1) the link-layer address of the > > sender of the fragment it received, (2) the datagram_tag of the > > fragment it received, (3) the link-layer address of the next hop, (4) > > a datagram_tag for the fragments it will send. The latter > > datagram_tag must be locally unique. > > This would also need another explanatory note after this paragraph; > for instance, "note that if node E has multiple network interfaces, > the VRB would have (5) the link-layer address of the sender of the > fragment it received, and (6) the link-layer address of the sender of > the fragment it will use." > > Technically, each fragment is identified by the combination of the > source link-layer address, the destination link-layer address, and the > datagram_tag as explained in Section 1. > > (excerpt from Section 1) > >> 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. The value of the datagram_tag only needs to be > >> locally unique to nodes A and B. > > I guess the reason to use the destination link-layer address is > that the text shown above and RFC 4944 take into account cases > when a node has multiple network interfaces. > > Then, E's VRB Table in Fugure 3 should have "L2 dest" as a the > "incoming" column and "L2 src" as a the "outgoing" column. But, > putting them into Figure 3 seems too much. Just adding note would > be enough, I think. > > [3] > > Upon forwarding the last fragment of a packet, the VRB table entry > > can be cleared, and reused for a future packet. If the last fragment > > of a packet is dropped, the VRB table entry can be invalidated by > > timeout. Its timeout value is set to a maximum of 60 seconds as the > > reassembly timeout defined in [RFC4944]. > > For the explanation about the basic mechanism of VRB, can we assume > fragments of an IPv6 packet are always received in order? > > In general, fragments could be received out of order. Because of that, > an intermediate node cannot determine which fragment is the last one > for the correspondent packet without any state on received fragments > in the VRB Table. Every active VRB entry is valid until its > expiration. > > However, I believe reordering of fragments rarely happens in reality > with networks which 6tisch WG or 6lo WG deal with. If this is the > case, I'd suggest to keep the paragraph as it is since it's simple and > easy to understand. We may add some text clarifying that this > optimization works under a certain condition, that is, fragments are > received in order. > > > A simple implementation may do away with any attempt to keep packet > > data in the virtual reassembly buffer. It then has to discard all > > non-first fragments for which a reassembly buffer is not already > > available (penalizing reordering, which however may be rare). > > I agree. > > [4] > > 4. Critique of VRB > > (snip) > > It is possible for a network to be composed of some nodes that > > implement VRB, and others that don't. Nodes that do not implement > > VRB reassemble the packet. > > The last sentence is forgotten to be removed...? > > Best, > Yatch > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- ________________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Analog Devices Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com ________________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
