[6lo] comments on draft-watteyne-6lo-minimal-fragment-00.txt

[Yasuyuki Tanaka <[e-mail]>]

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