Subject: Re: [6lowpan] LoWPAN simple fragment Recovery

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Jun 2009 07:54:40 +0200

Hi Fred:

128 includes a lot of overhead, mostly security; the real usable data
can be in the order of 80 bytes.
In practice RFC 4944 fixes an MTU of 1280 for 802.15.4. So 16 should
still be enough VERY strictly speaking. 

To be considered: some stacks are so constrained that they cannot
receive 2 fragmented packets in parallel so a very large packet will
lock resources for a very long time. Another angle is that ISA100.11a
nodes do not support IP fragments and PMTU discovery on the grounds that
the MTU is 1280.

But I thought that might be a bit short sighted. If we use different
media, with different max frame or security. If 6LoWPAN or an
implementation was to allow up to 1500 or 2048 we'd be in trouble. So I
went for 32 to start with, and I might have overshot. 

The sense of history is that we'll probably not increase MTU for 9K
packets on 802.15.4 and maybe we'll reduce the number of bits in my
fragment recovery header. This is certainly something that will pop up
at the WG to optimize once the group takes the draft aboard. There was a
rough consensus in SFO to accept the draft but the charter does not
really include this work. 

Keep you tuned :)

Pascal

>-----Original Message-----
>From: Fred Baker (fred)
>Sent: mercredi 17 juin 2009 00:52
>To: [email-masked]
>Cc: [email-masked]
>Subject: LoWPAN simple fragment Recovery
>
>reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came up
>with a question.
>
>Section 4 indicates that "The recovery mechanism must support highly
>fragmented packets, with a maximum of 32 fragments per packet." I
>agree that 32 128 byte fragments is a lot of fragments, but I'm
>concerned: there is discussion of allowing 9K packets. What happens
>when a 9K packet goes to a sensor? since 9K/128 is on the order of 70,
>you are going to have to reply "packet too big". If that is
>acceptable, why not limit this to 16 fragments, 128*16 being greater
>that 1500 bytes?
>
>Where did "32" come from?
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2009 08:21:36 +0200

On Jun 17, 2009, at 07:54, Pascal Thubert (pthubert) wrote:

> 80 bytes

Well.

MAC frame mac: 127 bytes
MAC header/trailer: 5 bytes
Adresses (usually, if EUI-64 is used): 18 bytes
Security Header: 0..14 bytes (depending e.g. on key identifier)
Security Trailer (MIC): 0/4/8/16 bytes

Depending on how security is being used, the MAC payload may be as low  
as 74 bytes.
With 6 bytes of fragment header overhead, we are at 68; with rounding  
to a multiple of 8, we are at 64.
1280/64 = 20.

The first fragment may have some additional header overhead (somewhat  
unlikely, but possible), so I'd say:

21 fragments

This is without a mesh header.
If a mesh header in the current worst case configuration is needed,  
make that 28 (!).

I think rounding up to 32 is about right.
5 bits for the sequence number also happens to match up with the 11  
bits needed for the datagram size.

Spending a bit or two of those for some form of huffman/rice coding  
might be the more appropriate way to save bytes in the FRACK packet,  
if that is a concern, because many packets will fit into much fewer  
(eg., 7 or less, 14 or less) fragments.  Or, simpler, trailing zeroes  
might be suppressed in the FRACK.

All this pesky bit fiddling...  But someone has to do it.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Jun 2009 11:16:51 +0200

Hi Carsten:

I love your suggestions. Thanks a lot :)

Since there is no additional data in the FRACK we could deduce the size
of the ack bitmap from the packet length, but I would not go that way.

Let's see what we have on the table

A) As you say we could elide trailing zeroes.
We'd use the first 2 bits to say how many bytes in the bitmap, trail all
zeroes.

Acknowledging within the first  6 fragments takes one octet coded as
00xxxxxx 
Acknowledging within the first 14 fragments takes one octet coded as
01xxxxxx xxxxxxxx 
Acknowledging within the first 22 fragments takes one octet coded as
10xxxxxx xxxxxxxx xxxxxxxx  
Acknowledging within the first 30 fragments takes one octet coded as
11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

B) Or we could use an encoding similar to the LOWPAN_NHC in the header
compression draft.

Acknowledging within the first 7 fragments takes one octet coded as
0xxxxxxx
Acknowledging within the first 14 fragments takes 2 octets coded as
10xxxxxx xxxxxxxx
Acknowledging within the first 21 fragments takes 3 octets coded as
110xxxxx xxxxxxxx xxxxxxxx 
Acknowledging within the first 28 fragments takes 3 octets coded as
1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx

Theoretically that could lead us as far as we care to go but it seems
that 28 is enough.
Also we might want to write right to left to avoid shifting bits around.

Conclusion: 

A) gives us up to 30 fragments and a very simple encoding as opposed to
28 for B
B) is more efficient in that it saves one octet for the 7th fragment
whereas A saves on octet on the 22nd, which is probably a much rarer
occasion.

I'd be more inclined to use B) for the slightly better compression but
I'd appreciate opinions on this. 

Opinions? Votes are:

A, B, or B+read right to left.

Pascal

>From: Carsten Bormann [mailto:[email-masked]]
>Sent: mercredi 17 juin 2009 08:22
>To: Pascal Thubert (pthubert)
>Cc: Fred Baker (fred);
[email-masked];
[email-masked]
>Subject: Re: [6lowpan] LoWPAN simple fragment Recovery
>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 17 Jun 2009 08:18:55 -0700

On Jun 17, 2009, at 8:12 AM, Fred Baker wrote:
> On Jun 16, 2009, at 11:21 PM, Carsten Bormann wrote:
>
> In which we put an Ipv6 header? :-)

I think Carsten meant 28 fragments, not bytes :-)

The Mesh Addressing header can consume up to 18 bytes per fragment.

--
Jonathan Hui

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jun 2009 16:55:06 +0200

Side-note

The draft in question is:
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-05

It is not clear to me why there is a need for 6LoWPAN to manage 
fragmentation below the IP layer (at the 6LoWPAN shim layer) vs managing 
fragmentation at the IP layer (IPv6 fragmentation and reassembly).

The motivation presented in the draft is doubtful, for example refers to 
IPv4 fragmentation, instead of IPv6.  It also refers to MSS of TCP, and 
not to IP fragmentation.

I am not sure where to look for motivation of doing fragmentation at the 
shim layer below IP for 6LoWPAN.

I may miss large parts of earlier discussion/documents.

Alex

Pascal Thubert (pthubert) a écrit :
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2009 19:44:31 +0200

On Jun 17, 2009, at 16:55, Alexandru Petrescu wrote:

> fragmentation below the IP layer

RFC 4919, section 4.3 and 5 (item 1).

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2009 19:50:43 +0200

> A, B, or B+read right to left.

Clearly C.

The length info already is in the MAC layer length field.
Transmitting it again in another couple of bits sounds wrong  
complexitywise.

Or do you think we will append other things to FRACKs at some point?

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2009 15:01:27 +0200

Carsten, sorry, I will write below something I have a hard time 
understanding since I participate in 6LoWPAN.

> RFC 4919, section 4.3 and 5 (item 1).

Indeed:"a fragmentation and reassembly adaptation layer must
        be provided at the layer below IP." and then rfc2460:
        "On any link that cannot convey a 1280-octet packet in one piece,
        link-specific fragmentation and reassembly must be provided at a
        layer below IPv6."

I doubt IETF specifies link-specific layers below IPv6.  I don't know of 
any[*].  Please point to an existing RFC Standards Track defining a 
layer below IPv6.

This is why I don't understand the goal of specifying 6LoWPAN 
fragmentation at a layer situated below the IPv6 layer.

I am wondering how this work could have been chartered at all... but I 
have surely missed earlier discussion and motivation.

Alex

[*] there are IETF IPv6-over-foo documents; they describe mainly
     mappings between addresses, constants for encapsulation, MTU values,
     etc.  Whereas here we talk about _logic_ to be implemented in a
     _new_ layer below IP - fragmentation and reassembly is such logic.
     Fully specifying such fragm/reassembly layers goes well beyond the
     typical IP-over-foo description.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Jun 2009 17:56:22 +0200

Alex,

there are lots of IP-over-foo documents that have much more logic than  
6LoWPAN.

-- the PPP series of documents, which by reference includes functions  
like ROHC (which has its own segmentation layer);
-- IP over ATM?
-- and how about MPLS (which also includes ROHC via RFC 4901);
-- and an example for something quite similar to 6LoWPAN (including  
fragmentation), RFC 3146 (IPv6 over Firewire)/RFC 2734 (IP over  
Firewire).

> fragmentation at a layer situated below the IPv6 layer.

It is a bit late to make that argument:
RFC 4919 (defining that goal) and RFC 4944 (specifying the protocol)  
were approved in 2007.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2009 18:59:48 +0200

Carsten Bormann a écrit :
> -- the PPP series of documents,

Right... PPP, EAP and PANA.

I think they can be used below IP _and_ above IP (EAP over 802.1x, EAP 
over Diameter; PPP over rs232, PPP over SSH; etc.)  PANA always over UDP.

In this vein, could the 6LoWPAN adaptation layer too run somewhere above 
IP?  If yes - wouldn't it be more efficient for the IP layer to perform 
the necessary fragmentation instead?

> which by reference includes functions 

I think ROHC also runs over application layers too.  I think it _mainly_ 
  runs above IP.

> -- IP over ATM?

I think IP over ATM has not much logic in it.  I see constants 
everywhere, no new logic. (by "logic" we both mean some behaviour to be 
implemented, more than just mappings of constants and definitions).

> -- and how about MPLS (which also includes ROHC via RFC 4901);

I can't comment on MPLS... I have yet to see it running on IPv6.

> fragmentation), RFC 3146 (IPv6 over Firewire)/RFC 2734 (IP over Firewire).

IPv6 over Firewire saying it performs the same fragmentation as IPv4 
over Firewire risks being a long stretch, because IPv6 and IPv4 behave 
differently with respect to fragmentation at IP layer.

> RFC 4919 (defining that goal) and RFC 4944 (specifying the protocol) 

Right... these being RFCs requesting comments: I offered my comments.

Alex

---

From: Fred Baker <[email-masked]>
Date: Tue, 16 Jun 2009 15:52:14 -0700

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Jun 2009 08:12:07 -0700

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Jun 2009 08:14:31 -0700

well, gee. My mention of putting the IPv6 header into 28 bytes was  
very tongue in cheek, but using IPv6 fragmentation instead of link  
layer fragmentation would require us to do exactly that. Am I mistaken?

If a link layer frame is less than the IPv6 MTU of 1280, it will have  
to be the link layer's job to get it there.

On Jun 17, 2009, at 7:55 AM, Alexandru Petrescu wrote:

> fragmentation below the IP layer (at the 6LoWPAN shim layer) vs  
> managing fragmentation at the IP layer (IPv6 fragmentation and  
> reassembly).
>
> The motivation presented in the draft is doubtful, for example  
> refers to IPv4 fragmentation, instead of IPv6.  It also refers to  
> MSS of TCP, and not to IP fragmentation.
>
> I am not sure where to look for motivation of doing fragmentation at  
> the shim layer below IP for 6LoWPAN.
>
>> still be enough VERY strictly speaking. To be considered: some  
>> stacks are so constrained that they cannot
>> went for 32 to start with, and I might have overshot. The sense of  
>> history is that we'll probably not increase MTU for 9K
>> really include this work. Keep you tuned :)
>> Pascal

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Jun 2009 08:35:37 -0700

If that's fragments, then that explains the utility of a five bit  
number. Thanks.

On Jun 17, 2009, at 8:18 AM, Jonathan Hui wrote:

>>> If a mesh header in the current worst case configuration is  
>>> needed, make that 28 (!).
>>

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 24 Jun 2009 11:42:19 -0400

Date: Wed, 17 Jun 2009 11:16:51 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

   [...]

   [...]

   Conclusion: 

   Opinions? Votes are:

None of the above.  I don't think it is worth adding this
much complexity just to reduce the size of the FRACK packet.
Reducing the overhead in the fragments would be helpful, but
I don't see much in the way of possibilities.

                                -Richard Kelsey