Re: [6lowpan] LoWPAN simple fragment Recovery

["Pascal Thubert (pthubert)" <[e-mail]>]

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