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

[Thomas Watteyne <[e-mail]>]

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 <[e-mail]>
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
> [e-mail]
> 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
________________________________________