Subject: Re: [lp-wan] I-D Action: draft-gomez-lpwan-fragmentation-header-00.txt

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Mar 2016 17:26:51 +0100

Hi Carles, Josep, Jon,

nice!

There have been a lot of requests for byte-exact slicing for RFC 4944
fragmentation.  This is a nice way to solve this, given the new
assumptions below.

Besides lower bit rates, the other new assumption you are exploiting is
that "... in LPWAN, ...   reordering [is] not expected".  "Not expected"
is different from "cannot happen".  The format actually works with
limited reordering, except for more uncertainty in memory allocation at
the receiver.  Do you expect the format to license receivers to throw
away out-of-order fragments?  In that case, we probably can save another
byte.  Or do you treat the question whether an implementation can handle
reordering as a quality of implementation issue?

By the way, the exact format is a bit innovative as it presumes 8-1/3
bit bytes :-)
(probably just an error in figure 1/2).
I would probably keep the datagram tag in the same place in both forms,
the 11-bit size field is the same size as the 11-bit offset field and
fits nicely after the 110xy dispatch constant.

Cons:

-- slurping away another 1/16 of the dispatch space.
-- creating an alternative way to do fragmentation that implementers of
other 6Lo standards will want to use, too, creating confusion and
interop issues.
Hmm.

Grüße, Carsten

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Optimized 6LoWPAN Fragmentation Header for LPWAN 
>         Authors         : Carles Gomez
>                           Josep Paradells
>                           Jon Crowcroft
> 	Filename        : draft-gomez-lpwan-fragmentation-header-00.txt
> 	Pages           : 8
> 	Date            : 2016-03-10
> 
> Abstract:
>    LPWAN technologies are characterized by a very limited data unit and/
>    or payload size, often one order of magnitude below the one in IEEE
>    802.15.4.  However, many such technologies do not support layer 2
>    fragmentation.  The 6LoWPAN fragmentation header defined in RFC 4944
>    represents very high overhead for LPWAN technologies, and it even
>    does not support transporting IPv6 datagrams that require
>    fragmentation over layer 2 technologies of a payload size below 13
>    bytes.  This specification defines an optimized 6LoWPAN fragmentation
>    header for LPWAN.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gomez-lpwan-fragmentation-header/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-gomez-lpwan-fragmentation-header-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 10 Mar 2016 19:19:19 +0100

Hi Carsten,

Thanks a lot for your (quick!) insight and attentiveness!

> reordering as a quality of implementation issue?

Are you thinking about removing the datagram_tag field?

In that case, e.g. the following could happen:

- Fragment received (datagram_tag = A; offset = 2)
-   {Several fragments from two datagrams A and B are lost}
- Fragment received (datagram_tag = B; offset = 3)

In the previous example, if the datagram_tag field is not present, and if
no additional support (e.g. sequence numbers) is available at the lower
layer, the receiver may believe it is reconstructing correctly an original
datagram. (Even with lower layer sequence numbers there could still be a
chance of undue reassembly.)

... Or maybe could we assume that such situation has relatively low
probability and the (huge!) saving of a further byte compensates admitting
this possible issue?

(Roughly, the greater the number of fragments required for a datagram, the
lower the probability of such event happening.)

> (probably just an error in figure 1/2).

Oh, good catch! :-)
We did not intend to innovate in this area ;-)

> fits nicely after the 110xy dispatch constant.

Sure, this simplifies processing.

> other 6Lo standards will want to use, too, creating confusion and

True.

At this moment, I don't see how we could overcome the cons. Hopefully it
is a price that can be assumed considering the significant benefits in
terms of overhead decrease, and in increasing the range of layer two
technologies that may support IPv6...

Again, thanks for your comments!

Cheers,

Carles

> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Mar 2016 20:39:35 +0100

> Are you thinking about removing the datagram_tag field?

No, I was thinking about turning datagram_offset/_size into a fragment
serial/count.  Apart form making sorting in reordered fragments much
harder, this takes away the nice pre-allocation that the current format
has.  But it surely is shorter.

Compare Pascal's various attempts at a more efficient, ACKable
fragmentation format.  (He needs the serial because an ACK vector is too
expensive otherwise.)

> 
> In that case, e.g. the following could happen: [snipped]

There is a reason AAL5 had a per-packet CRC...

(Not a problem in the Internet of Things, because application layer
integrity protection will catch all packet errors anyway, leading to:)

> probability and the (huge!) saving of a further byte compensates admitting

Even though it would make a welcome incentive to actually do the
application layer security, I think that assumption would be a bit
radical, though.

Grüße, Carsten

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 11 Mar 2016 14:45:11 +0100

Hi Carsten,

> has.  But it surely is shorter.

[snipped]

In order to make it easier to compare the two approaches (3-byte vs 2-byte
approaches) could you please provide the format you are considering for
the 2-byte one?  (My last attempt of figuring out failed a little bit :))

To ease an overhead comparison, here are some numbers for the two options,
plus the default one of RFC 4944:

 - 4944 stands for RFC 4944 fragmentation header
 - 3B stands for the 3-byte format in draft-gomez-lpwan-fragmentation-header
 - 2B stands for a 2-byte format

                   +-------------------------------------------------------+
                   |                IPv6 datagram size (bytes)             |
                   +-------------+-------------+-------------+-------------+
                   |     11      |    40       |     100     |     1280    |
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|L2 payload (bytes)|4944| 3B | 2B|4944| 3B | 2B|4944| 3B | 2B|4944| 3B | 2B|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       10         |----|  2 | 2 |----|  6 | 5 |----| 15 | 13|----| 183|160|
+------------------+----+----+---+----+----+---+----+----+---+---------+---+
|       15         |  1 |  1 | 1 |  5 |  4 | 4 | 13 |  9 | 8 | 160| 107| 99|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       20         |  1 |  1 | 1 |  4 |  3 | 3 | 12 |  6 | 6 | 159|  76| 72|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       25         |  1 |  1 | 1 |  3 |  2 | 2 | 7  |  5 | 5 | 80 |  59| 56|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       30         |  1 |  1 | 1 |  2 |  2 | 2 | 5  |  4 | 4 | 54 |  48| 46|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
       L2 overhead (in terms of L2 data units) required to transport
                                 an IPv6 datagram

                   +-------------------------------------------------------+
                   |                IPv6 datagram size (bytes)             |
                   +-------------+-------------+-------------+-------------+
                   |     11      |    40       |     100     |     1280    |
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|L2 payload (bytes)|4944| 3B | 2B|4944| 3B | 2B|4944| 3B | 2B|4944| 3B | 2B|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       10         |----|  6 | 4 |----| 18 | 10|----| 45 | 26|----| 768|320|
+------------------+----+----+---+----+----+---+----+----+---+---------+---+
|       15         |  0 |  0 | 0 | 24 | 12 | 8 | 64 | 27 | 16| 799| 321|198|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       20         |  0 |  0 | 0 | 19 |  9 | 6 | 59 | 18 | 12| 794| 228|144|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       25         |  0 |  0 | 0 | 14 |  6 | 4 | 34 | 15 | 10| 399| 177|112|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
|       30         |  0 |  0 | 0 |  9 |  6 | 4 | 24 | 12 |  8| 269| 144| 92|
+------------------+----+----+---+----+----+---+----+----+---+----+----+---+
       Adaptation layer fragmentation overhead (in bytes) required
                       to transport an IPv6 datagram

In terms of L2 data units required to transport an IPv6 datagram, the
improvement of a 2-byte fragmentation header over the 3-byte one can be
noticed mostly for very low (i.e. <= 15 byte) L2 payload size.

In terms of total number of fragmentation header bytes, the 2-byte format
provides significant improvement over the 3-byte one, which increases as
the L2 payload decreases. The improvement in terms of overall number of
bytes (IPv6 datagram size plus fragmentation headers), which does not take
into account the L2/L1 headers, is between 3.7% and 28%.

According to draft-minaburo-lp-wan-gap-analysis, there are some
technologies with L2 payload sizes in the range below around 30 bytes.
These would be the ones which would get the highest relative benefit from
the 2-byte format in terms of bytes in the air.

So the question is: do we prefer the 3-byte format (simple) or the 2-byte
format (possibly more complex) ?

> There is a reason AAL5 had a per-packet CRC...

Sure!

> application layer security, I think that assumption would be a bit

Agreed.

Cheers,

Carles