Works for me Michel : So we need answers from the list. The choice on the table is either to reduce the datagram_tag field to 256 as illustrated below or to use a 4 bytes unit for links with large MTUs (more than 127 octets).
What do people think is more appropriate to their needs? Pascal From: Michel Veillette <[email protected]> Sent: jeudi 17 janvier 2019 18:56 To: Pascal Thubert (pthubert) <[email protected]>; Dario Tedeschi ([email protected]) <[email protected]> Cc: [email protected] Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small Hi Pascal I'm sorry, the propose format in my last email doesn't fix the datagram total length limitation. 32 fragments of 512 bytes still limit the datagram to 16 kB. Based on the following constraints: * Up to 256 active datagram * Up to 32 fragments * Up to 64kB datagram * Up to 2kB fragment (32 fragments of 2 kB = 64 kB datagram) I recommend the following Dispatch type formats. Alternatively, the original format with a 4 bytes unit will work for us but doesn't seem to address all potential issues. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0|X| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| sequence| fragment_size | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 Y| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFRAG Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Michel From: Michel Veillette Sent: Wednesday, January 16, 2019 9:04 PM To: 'Pascal Thubert (pthubert)' <[email protected]<mailto:[email protected]>>; Dario Tedeschi ([email protected]<mailto:[email protected]>) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small Using a 4 bytes unit for size and offset doesn't seem to fully solve all issues, this solution is still limited to 8 kB datagram. About the dual formats proposal, I'm not convinced this problem is such we can't find a single format acceptable for everyone. If maintaining an overhead of 6 bytes is a must, the solution below might be the best compromise. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0| fragment_size |X|E| sequence| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 0|Y| Reserved | datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFRAG Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Michel From: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 16, 2019 9:59 AM To: Michel Veillette <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small Hello Michel I have not seen a strong argument against saying that the unit for size and offset is 4 bytes if the MTU is larger than 127 bytes. This keeps classical 802.15.4 with 1 octet and allows fragments of 512 with 802.15.4g. that would be the simplest and most economical way of doing it. The only issue is that the last fragment might be less than the fragment_size, but that can be found based on the frame size. This seems to be the best tradeoff to me. As an alternate we could define both of the formats that you copied below, one as 1 1 1 0 1 0 and the other as 1 1 1 0 1 1 as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0|X| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| sequence| fragment_size | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 Y| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFRAG Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vs. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 1 0|X| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| sequence| fragment_size | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 1 1 Y| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFRAG Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ what do you think? Pascal From: Michel Veillette <[email protected]<mailto:[email protected]>> Sent: mardi 15 janvier 2019 20:14 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small Hi Pascal Did we reach any consensus about the RFRAG Dispatch type format? See the last two formats proposed bellow. Regards, Michel From: Michel Veillette Sent: Tuesday, January 8, 2019 2:28 PM To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: draft-ietf-6lo-fragment-recovery maximum fragment size too small Hi Pascal A 8 bits "datagram_tag" is a strict minimum in our case and peoples might have good arguments to keep this field aligned with RFC4944. I also don't see how to implement a 10 bits or 12 bits "datagram_tag" without adding an octet. I can go either way but my preference are: - 16 bits datagram_tag - 10 bits fragment_size - 16 bits fragment_offset 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0|X| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| sequence| fragment_size | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 Y| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFRAG Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vs. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 0|X| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| sequence| fragment_size | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 1 0 1 Y| datagram_tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RFRAG Acknowledgment Bitmap (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Michel
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
