Subject: [6lo] fragment forwarding document

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Jul 2017 01:04:45 +0200

I've read draft-thubert-6lo-forwarding-fragments, and I think that we
should go ahead with it.  Here are some detailed comments.  I can't say
that I understand all the processing required yet, but it's clear that
the authors do: the text simply needs improvement.

pg: 6, section 4.1:

 Sequence:  5 bit unsigned integer; the sequence number of the
      fragment.  Fragments are sequence numbered [0..N] where N is in
      [0..31].  As long as the overheads enable a fragment size of 64
      bits or more, this enables to fragment a packet of 2047 octets.
      ^^^^ <- I think you mean octets?

 Fragment_offset:  11 bit unsigned integer; when set to 0, this field
      indicates an abort condition; else, its value depends on the value
      of the Sequence.  When the sequence is not 0, this field indicates
      the offset of the fragment in the compressed form.  When the
      sequence is 0, denoting the first fragment of a datagram, this

reword. I think it means:
  if Sequence > 0; fragment_offset == 0 => abort.
                 ; else offset of fragment
  if Sequence ==0; fragment_offset is total size of datagram.

Are FRFRAG-ACK's subject to 6loRH compression in anyway?
(I don't think it helps, but, whenever I see a potential series of zeros, I
wonder)

section 5 says:
   The process ensures that at every hop, the source
   MAC address and the datagram_tag in the received fragment are enough
   information to send the RFRAG Acknowledgment back towards the source
   6LoWPAN endpoint by reversing the MPLS operation.

It seems that we are assuming SLAAC built addresses using EUI-64s?
(which could well be 2-byte short addresses too!)  otherwise, mapping
From MAC address back to an IPv6 address is not possible?

then says:
   It is
   expected that the upper layer retries obey the same or friendly rules
   in which case a single round of fragment recovery should fit within
   the upper layer recovery timers.

"the same or friendly rules"  <-- missing a word?

seciton 6:
   Upon the first
   fragment, the routers along the path install a label-switched path
   (LSP), and the sollowing fragments are label-switched along that
   path.

s/sollowing/following/

6.1: s/ia route lookup/a route lookup/

  allocates a label-swap entry indexed by (MAC_previous,
  DT_previous) that contains (MAC_next, DT_next)

It seems that really do have to go read LSP documents to understand things :-)
RFC3031 had better be a normative reference then, or section 6.1 needs to
have some pictures and much more explanation.  I will have to go re-read
3031 to understand what a "label-swap entry" is exactly.

   change the source MAC address to from MAC_prev to MAC_self

"to from" --- is this correct, or is there an extra word here?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jul 2017 11:00:15 +0000

Hello Michael:

Huge thanks.

Let's see:

pg: 6, section 4.1:

[Pascal] that's a oups, fixed in 07.

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

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

[Pascal] This is effectively a big stone you are unturning. The intent of the initial logic is:

If fragment_offset == 0; forward of you can and cleanup (aka abort)
          ; else
                  if Sequence ==0; fragment_offset is total size of datagram
                                      ; else fragment_offset is offset in the datagram in octets

[Pascal] With the current text (sequence, offset) tuple of (0, 0) is significant whereas with your proposal, this tuple becomes a protocol error. Either way, we probably need some more text what nodes should do in that case. I'm not too much in favor of creating an error case; error flows have a tendency to not perform well.

[Pascal] Let's consider this: (0,0) could be useful, because it carries the original IP header so there's a chance it goes all the a to the reassembly end point even if the forwarding state is broken midway; this could be important because the end point is where the buffers are wasted. And because it may be routed differently than a previous (0, X>0), a (0, 0) may fail to clean up state along the old path even when the old path is not broken. We'll note that the old path may be cleanup all the way back (to the breakage if there's one) by a reset message from the end point. That reset message could be stimulated by receiving  a (0, 0). But with the 6LoWPAN signaling as it stands now, the end point may not recognize that this is the same IP packet because the datagram tags would possibly be different, being switched differently along different routes. If we care to take that path, we need the end points to exchange end-to-end IDs for the flows. Doable but expensive. Worth it?

[Pascal] In order to protect the future, I'd say that (0, 0) should be supported. It should be routed, using the same label path if one exists that is not broken on this next hop. Cleanup should be performed. I reformed the text along those line

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

[Pascal] No to the 6LoRH piece, but possibly yes to the idea of compression. You'll find in earlier versions of the draft that a compression of the bitmap was proposed. I spent iterations adding and removing it based on one person's feedback; not an easy choice since it is a tradeoff between over the air performance and code complexity. 

More in section 6.2 of https://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06

Let's reach consensus on that! 

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

section 5 says:

It seems that we are assuming SLAAC built addresses using EUI-64s?
(which could well be 2-byte short addresses too!)  otherwise, mapping From MAC address back to an IPv6 address is not possible?

[Pascal] I do not see how/why. 

[Pascal] All it means is that the MPLS operation address is indexed by the tuple (incoming link - as identifies by smac, label - the datagram tag). No big news there, once created an MPLS LSP can carry non IP traffic. 

[Pascal] The novelty is rather that the LSP is created on the fly with the first fragment of an IP packet, and removed once the packet as fully flown through.

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

then says:
   It is

[Pascal] slight rewording, added ref to 8085 
[Pascal] 

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

section 6:
   Upon the first

s/sollowing/following/

[Pascal] done, thanks!

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

It seems that really do have to go read LSP documents to understand things :-)
RFC3031 had better be a normative reference then, or section 6.1 needs to have some pictures and much more explanation.  I will have to go re-read
3031 to understand what a "label-swap entry" is exactly.

[Pascal] well, this refers to text in this spec:
"
allocates an abstract label-swap entry indexed by (MAC_previous, DT_previous) that contains (MAC_next, DT_next)
"
Maybe some reorg is needed to highlight that structure.

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

[Pascal] 
[Pascal] fixed typo : )

--

I just pushed 07. Thanks again Michael!

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jul 2017 12:28:20 -0400

> [Pascal] With the current text (sequence, offset) tuple of (0, 0) is
    > significant whereas with your proposal, this tuple becomes a protocol
    > error. Either way, we probably need some more text what nodes should do
    > in that case. I'm not too much in favor of creating an error case;
    > error flows have a tendency to not perform well.

I wasn't suggesting to change the protocol, I was trying to explain it.
I clearly did not understand it!

    > [Pascal] Let's consider this: (0,0) could be useful, because it carries
    > the original IP header so there's a chance it goes all the a to the
    > reassembly end point even if the forwarding state is broken midway;
    > this could be important because the end point is where the buffers are
    > wasted. And because it may be routed differently than a previous (0,
    > X>0), a (0, 0) may fail to clean up state along the old path even when
    > the old path is not broken. We'll note that the old path may be cleanup
    > all the way back (to the breakage if there's one) by a reset message
    > from the end point. That reset message could be stimulated by receiving
    > a (0, 0). But with the 6LoWPAN signaling as it stands now, the end
    > point may not recognize that this is the same IP packet because the
    > datagram tags would possibly be different, being switched differently
    > along different routes. If we care to take that path, we need the end
    > points to exchange end-to-end IDs for the flows. Doable but
    > expensive. Worth it?

I think you've jumped ahead of me.
You are talking about a way to clean up state given multiple possible paths.

I'm just barely at the point where I can understand how the state is
created :-) 

    > [Pascal] All it means is that the MPLS operation address is indexed by
    > the tuple (incoming link - as identifies by smac, label - the datagram
    > tag). No big news there, once created an MPLS LSP can carry non IP
    > traffic.

I think you are saying that since the final fragment assembler will have
reassembled the L3 header, that it will know where to send the ACK.

    > "to from" --- is this correct, or is there an extra word here?

okay, good. I thought that maybe there was some extra meaning I didn't get.