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:[email protected]] >Sent: mercredi 17 juin 2009 08:22 >To: Pascal Thubert (pthubert) >Cc: Fred Baker (fred); [email protected]; [email protected] >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 [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
