[6lowpan] (cutting overhead) RE: LoWPAN simple fragment Recovery

[Rene Struik <[e-mail]>]

Hi Pascal:

If one does fragmentation and has multiple frames, one should be able to compress 802.15.4 headers for the subsequent frames. 

One could proceed as follows:
a) first frame could use full header;
b) subsequent frames would use truncated MAC header overhead (under assumption that this can be faithfully reconstructed at recipient's end (who stores header intelligence if frame pending bit is set).
c) crypto overhead (message authentication tag) can be seriously shortened for typical frames.

This would potentially lead to the following:
a) first frame has full header;
b) subsequent frames: 5 octets of non payload fields total;
- reduced MAC header: 3 octets (sFCF: 1 octet; DSN: 1 octet; Header fields: 0 octets; AuxSecHeader: 1 octet); 
- reduced crypto expansion: 2 octets (typically - if realizing what I dubbed "Frame Security Dream");
- elided CRC-16: 0 octets (if one uses authenticity tag (with default key if no security)).
Thus, with frame fragmentation, all but the first frame may have payload field of up to 122 octets.

This is not always possible with 802.15.4-2006 techniques, but intention is that 802.15.4e amendment enables this.
For further info, cf. IEEE 802.15.4e document: 15-08-0828-08-004e-security-and-efficiency-enhancements.ppt

I should remember to take this into account when writing up the draft text for overhead reduction techniques for 802.15.4e, making sure to make the link to frame pending stuff. 

Any comments appreciated.

Best regards, 

Rene

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, June 17, 2009 5:17 AM
To: Carsten Bormann
Cc: [e-mail]; [e-mail]; Fred Baker (fred)
Subject: Re: [6lowpan] LoWPAN simple fragment Recovery

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

>-----Original Message-----
>From: Carsten Bormann [mailto:[e-mail]]
>Sent: mercredi 17 juin 2009 08:22
>To: Pascal Thubert (pthubert)
>Cc: Fred Baker (fred);
[e-mail];
[e-mail]
>Subject: Re: [6lowpan] LoWPAN simple fragment Recovery
>
>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

_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan