Subject: Re: [6lo] WG Last Call: draft-ietf-6lo-minimal-fragment-01

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Jun 2019 14:39:48 +0000

Hello Yatch

This dates a bit but I think none of us answered so let me take a look:

> 
> (1) https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-01#section-2.2
> >                                             Assuming 1 kB reassembly
> >    buffers, typical nodes only have enough memory for 1-3 reassembly
> >    buffers.
> 
> Here, "Assuming a 1kB reassembly buffer"? (singular)

Fixed in 02

> 
> 
> (2) https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-01#section-7
> 
> These two drafts has newer versions:
> 
> > [I-D.ietf-lwig-6lowpan-virtual-reassembly]
> > [I-D.thubert-6lo-fragment-recovery]
> 

Version are automatically added at the next publication but I replaced draft-thubert by draft-ietf

> https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly-01
> https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-02
> 

Many (delayed) thanks, Yatch. Hope I see you in Montreal and go for that Mexican again.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Jun 2019 15:05:44 +0000

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.

>    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.
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.

> 
>    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.
"

> 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

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Fri, 21 Jun 2019 17:14:46 +0200

Dear Pascal,

Many thanks for your feedbacks! 

Best,
Giorgos

> On Jun 21, 2019, at 17:05, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Georgios
> 

I see the scenario. Thx.

> 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.

> “

Seems good to me.

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jun 2019 12:59:18 +0000

Hello Dominique:

Many thanks for your review! 
Please see below:

> Section 1, Overview:
> "Each fragment can be uniquely identified by the source and destination link-
> layer addresses of the frame that carries it, and the datagram_tag."
> It seems to me that "datagram_offset" should also be mentioned here as
> contributing to uniquely identifying a fragment.

Yes, this text was doubly wrong. 
In my mind it is enough that the destination is not part of uniqueness, the datagram_tag is unique to the source. But RFC 4944 has it differently, quoting section 5.3:
"
   The recipient of link fragments SHALL use (1) the sender's 802.15.4
   source address (or the Originator Address if a Mesh Addressing field
   is present), (2) the destination's 802.15.4 address (or the Final
   Destination address if a Mesh Addressing field is present), (3)
   datagram_size, and (4) datagram_tag to identify all the link
   fragments that belong to a given datagram.
"

Proposed change:

"
Each datagram can be uniquely identified by the source and final destination link-layer addresses of the frame that carries it, the fragment_size and the datagram_tag.
Each fragment can be identified within its datagram by the datagram-offset.
"

------------------
 
> Section 2.2
> "Assuming the topology from Figure 2, where nodes A, B, C and D all send
> packets through node E." Incorrect grammatical construct.
> 

What about
"
To illustrate this we use the topology from topology from Figure 2, where nodes A, B, C and D all send packets through node E.
"

-----------------

> 
> Section 3
> "Each VRB table entry can be 12 B (assuming 16-bit link-layer addresses)."
> It is not immediately obvious to me why 12. I guess I could try to figure it out.
> But [ARTICLE] says 20. Probably under a different assumption.
> Could you provide a detailed count, to spare the reader the exercise?
> BTW, in [ARTICLE], it seems to me that some means and remembering which
> fragment have already been forwarded are missing. The key sentence is "After
> having forwarded the last fragment, node B clears that VRB entry", but how
> does node B knows is has forwarded all fragments? The same comment applies
> to draft-ietf-lwig-6lowpan-virtual-reassembly-01. But I'm digressing here.

I'd like to remove that text altogether.
In some cases there's a need to keep some bytes form the previous fragment because the expansion and recompression of the 6LoWPAN header lead to lower compression. I'd rather indicate the abstract data that can be found in the VRB.

What about:

"The abstract data in the VRB contains at a minimum the MAC address of the predecessor and that of the successor, and the datagram_tag used by the predecessor and the datagram_tag that this node will swap with it. The VRB may need to store a few octets from the last fragment that may not have fit within MTU and that will be prepended to the next fragment.
"

------------------------
 
> Section 7, references
> Ref [ARTICLE] is dated 2009, I guess you mean 2019. Besides, I could only find
> the HAL archive, I suppose this is accepted for publication, but not published
> yet.
> Oops, just saw that Georgios already uncovered this nit.
> 
> 
> 

fixed : )

Many thanks!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jun 2019 14:11:35 +0000

Hello Carles:

02 was published with the comments listed below addressed.

All the best,

Pascal

> -----Original Message-----
> From: 6lo <[email-masked]> On Behalf Of Carles Gomez Montenegro
> Sent: mercredi 15 mai 2019 09:35
> To: [email-masked]
> Subject: Re: [6lo] WG Last Call: draft-ietf-6lo-minimal-fragment-01
> 
> Dear 6lo WG,
> 
> The WGLC for draft-ietf-6lo-minimal-fragment-01 is now closed.
> 
> During the WGLC, comments and reviews have been provided by Yasuyuki
> Tanaka, Georgios Papadopoulos and Dominique Barthel. We would like to
> thank all the reviewers for checking the document and kindly making
> suggestions for improving it.
> 
> @Authors: the feedback received requires updating the document. Please
> update the draft based on the comments received.
> 
> Thanks,
> 
> Shwetha and Carles
> 
> 
> > Dear 6lo WG,
> >
> > Authors of draft-ietf-6lo-minimal-fragment-01 expressed in IETF 104
> > that they believe that the document is ready for WGLC. No comments or
> > objections were made in this regard.
> >
> > Therefore, this email starts a WGLC for
> > draft-ietf-6lo-minimal-fragment-01:
> > https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-01
> >
> > The WGLC will end on Wednesday, 8th of May.
> >
> > Please provide your feedback on the document on the mailing list, even
> > if it is just a short "looks good" statement.
> >
> > Thank you in advance.
> >
> > Cheers,
> >
> > Shwetha and Carles
> >

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 28 Jun 2019 08:55:47 +0200

Hello Pascal and co-authors,

Thanks for addressing the WGLC comments in -02.

The document is now ready to continue its progress towards the IESG.

Cheers,

Shwetha and Carles