Subject: [6lo] [Fwd: New Version Notification for draft-gomez-6lo-optimized-fragmentation-header-00.txt]

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 25 Oct 2016 10:51:44 +0200

Dear 6Lo WG,

Please find below the pointers to our
draft-gomez-6lo-optimized-fragmentation-header-00 draft.

This document proposes a more lightweight and compact 6LoWPAN
fragmentation header, compared with the one defined in RFC 4944.

Those of you who are also following the LPWAN WG activity will realize
that this is the same format that had been proposed for LPWAN in the past
(*). However, in Berlin it was suggested that this format could be
submitted for consideration of the 6lo WG.

The motivation, some observations and the performance analysis in the
document have been adapted to the 6LoWPAN / 6Lo context.

Comments are welcome and appreciated!

Cheers,

Carles

(*) An even more lightweight format, which however is not compatible with
the 6LoWPAN dispatch, has now been defined for the LPWAN WG:
https://tools.ietf.org/html/draft-gomez-lpwan-fragmentation-header-03

---------------------------- Original Message ----------------------------
Subject: New Version Notification for
draft-gomez-6lo-optimized-fragmentation-header-00.txt
From:    [email-masked]
Date:    Sun, October 23, 2016 9:15 pm
To:      "Jon Crowcroft" <[email-masked]>
         "Carles Gomez" <[email-masked]>
         "Josep Paradells" <[email-masked]>
--------------------------------------------------------------------------

A new version of I-D, draft-gomez-6lo-optimized-fragmentation-header-00.txt
has been successfully submitted by Carles Gomez and posted to the
IETF repository.

Name:		draft-gomez-6lo-optimized-fragmentation-header
Revision:	00
Title:		Optimized 6LoWPAN Fragmentation Header
Document date:	2016-10-23
Group:		Individual Submission
Pages:		8
URL:           
https://www.ietf.org/internet-drafts/draft-gomez-6lo-optimized-fragmentation-header-00.txt
Status:        
https://datatracker.ietf.org/doc/draft-gomez-6lo-optimized-fragmentation-header/
Htmlized:      
https://tools.ietf.org/html/draft-gomez-6lo-optimized-fragmentation-header-00

Abstract:
   RFC 4944 specifies 6LoWPAN fragmentation, in order to support the
   IPv6 MTU requirement over IEEE 802.15.4-2003 networks.  The 6LoWPAN
   fragmentation header format comprises a 4-byte format for the first
   fragment, and a 5-byte format for subsequent fragments.  This
   specification defines a more efficient 3-byte, optimized 6LoWPAN
   fragmentation header for all fragments.

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.

The IETF Secretariat

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 25 Oct 2016 13:30:45 -0400

> fragmentation header, compared with the one defined in RFC 4944.

This seems like an improvement to me, though I'm new here.

But this is a good time to ask my newbie question:  I see this
definition of the "datagram size" field:

   datagram_size: This 11-bit field encodes the size of the entire IP
   packet before link-layer fragmentation (but after IP layer
   fragmentation).  For IPv6, the datagram size SHALL be 40 octets (the
   size of the uncompressed IPv6 header) more than the value of Payload
   Length in the IPv6 header [RFC4944] of the packet.  Note that this
   packet may already be fragmented by hosts involved in the
   communication, i.e., this field needs to encode a maximum length of
   1280 octets (the required by IPv6).

Naively, it seems to me that link fragmentation is at a layer lower than
link compression (e.g., LOWPAN_IPHC), so this datagram_size value is the
length of the IPv6 packet (possibly an IPv6 fragment) as compressed by
LOWPAN_IPHC.  If that is so, the above text isn't quite right, as
e.g. the compressed packet might be shorter than the (reconstructed)
Payload Length in the IPv6 header.

Now maybe I'm wrong, and "datagram size" is the length of the
uncompressed IPv6 packet, but then I don't see how the receiver is to
know when all of the fragments have arrived.

Dale

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Oct 2016 11:22:35 +0000

Hello Dale:

I agree... I think that the idea was to make sure that the buffer you prepare is big enough for the uncompressed form.

When Jonathan and I wrote a proposed rework we changed that as you suggest:
https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02 
"
   In the following sections, the semantics of "datagram_tag,"
   "datagram_offset" and "datagram_size" and the reassembly process are
   changed from [RFC4944] Section 5.3.  "Fragmentation Type and Header."
   The size and offset are expressed on the compressed packet per
   [RFC6282] as opposed to the uncompressed - native packet - form.
"
The rework addressed the problems discussed in the attached slides, and which are still fully present today.
The work needs support to move on. Last I checked interest was really limited.

Note also this text in RFC 6282:
"

   Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6
   datagrams that do not fit within a single link frame.  Section 5.3 of
   [RFC4944] defines the fragment header's datagram_size and
   datagram_offset values as the size and offset of the IPv6 datagram
   before compression.  As a result, all fragment payload outside the
   first fragment must carry their respective portions of the IPv6
   datagram before compression.  This document does not change that
   requirement.  When using the fragmentation mechanism described in
   Section 5.3 of [RFC4944], any header that cannot fit within the first
   fragment MUST NOT be compressed.

"

Regards;

Pascal

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: mardi 25 octobre 2016 19:31
To: Carles Gomez Montenegro <[email-masked]>
Cc: [email-masked]
Subject: [6lo] draft-gomez-6lo-optimized-fragmentation-header-00

But this is a good time to ask my newbie question:  I see this definition of the "datagram size" field:

Naively, it seems to me that link fragmentation is at a layer lower than link compression (e.g., LOWPAN_IPHC), so this datagram_size value is the length of the IPv6 packet (possibly an IPv6 fragment) as compressed by LOWPAN_IPHC.  If that is so, the above text isn't quite right, as e.g. the compressed packet might be shorter than the (reconstructed) Payload Length in the IPv6 header.

Now maybe I'm wrong, and "datagram size" is the length of the uncompressed IPv6 packet, but then I don't see how the receiver is to know when all of the fragments have arrived.

Dale

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

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 26 Oct 2016 11:35:54 -0400

"Pascal Thubert (pthubert)" <[email-masked]> writes:
> I agree... I think that the idea was to make sure that the buffer you
> prepare is big enough for the uncompressed form.

That is a useful property.

> https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02 
[...]
> The work needs support to move on. Last I checked interest was really limited.

As a general rule, people will show interest if they're being bitten by
the problem in practice.  If there isn't much interest, that would mean
that people aren't running into these problems in practice.  It's not
clear to me why that would be.

> Note also this text in RFC 6282: [...]

OK, I can see how that makes the packet reconstructable, as complicated
as that system is.  I do wonder why it was chosen, though, as it seems
both more complicated and less natural than separating compression and
fragmentation into two layers.

Dale