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

["Pascal Thubert (pthubert)" <[e-mail]>]

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