Re: [6lo] draft-ietf-6lo-fragment-recovery compress size

[Dario Tedeschi <[e-mail]>]

Hi Pascal,

Thanks for the clarification.

I agree that offsets in compressed form make more sense, if one 
considers RFC 8138.

Regards
Dario


On 1/22/19 2:10 AM, Pascal Thubert (pthubert) wrote:
>
> To your last question Michel, also as an answer to Dario:
>
> I think that the biggest contributor is the source and destination 
> address, since the source may be elided on the first hop and the 
> destination may be elided on the last hop. In intermediate hops, the 
> source and destination (that are global addresses as opposed to your 
> example) are not mapped on the MAC addresses thus not compressed, at 
> least statelessly.
>
> Also note vs. your example that I’d use RFC 8138 for the routing 
> header; the cool thing is that the size can only go down. Else you 
> need to allow an additional slack as discussed below.
>
> For Dario: the slack is basically done by leaving enough room for both 
> source and destination to go uncompressed or compressed worst case 
> (e.g., within a subnet the prefix can be coming from the context all 
> the way through). Same goes for hlim if it is compressed on the first 
> hop, which I would not recommend if multihop is expected.
>
> Slack is done by sending a first fragment that  that does not fill the 
> MTU. E.g. if the MTU is 127, and you compressed IID of the source 
> address based on EUI-64 and the hlim, then build the first fragment as 
> if the MTU was 118…
>
> Note that a datagram_offset  based on the uncompressed form expects 
> the exact same packet out of the compressor, and that RFC 8138 removes 
> the consumer routing headers. To Dario’s question this is an exception 
> to RFC 8200. If we use the offset in the original packet and a 
> fragment is routed with source routing, we’ll need to reassemble at 
> each hop, which defeats the purpose.
>
> All the best;
>
> Pascal
>
> *From:* 6lo <[e-mail]> *On Behalf Of * Pascal Thubert 
> (pthubert)
> *Sent:* lundi 21 janvier 2019 22:57
> *To:* Michel Veillette <[e-mail]>
> *Cc:* Dario Tedeschi ([e-mail]) <[e-mail]>; [e-mail]
> *Subject:* Re: [6lo] draft-ietf-6lo-fragment-recovery compress size
>
> Hello Michel
>
> I already answered that today, actually: )
>
> There is no such assumption but the node that changes the size also 
> needs to change the offset on all fragments.
>
> The expectation is that only the first fragment may change. The delta 
> offset that happens on the first fragment must be applied on all 
> further fragments on both length and offset fields as an additive or 
> substractive constant. I need to write that clearly.
>
> Now if you prefer to go back to using offsets in the uncompressed form 
> please let us know by answering my earlier mail today : )
>
> All the best
>
> Pascal
>
>
> Le 21 janv. 2019 à 22:43, Michel Veillette 
> <[e-mail] 
> <mailto:[e-mail]>> a écrit :
>
>     Hi Pascal
>
>     Draft "draft-ietf-6lo-fragment-recovery" seem to assume that the
>     size of the compressed header stay fix while traveling the RPL domain.
>
>     For example:
>
>       "In this specification, the size and offset of the fragments are
>     expressed on the compressed packet."
>
>      "The last fragment for a datagram is recognized when its
>     fragment_offset and its fragment_size add up to the datagram_size."
>
>     However, fields HLIM [RFC6282], CmprI and CmprE [RFC6554] may have
>     an impact on the compressed header size if the maximum compression
>     is applied at each hop.
>
>     Is this problem addressed in the draft?
>
>     Are you aware of other IPv6 fields or options which can cause this
>     issue?
>
>     How this issue should be addressed?
>
>     I tried to illustrate this problem in the example bellow:
>
>     IPv6 packet
>
>       - IPv6 packet header
>
>         - Hop limit = 66 (elided)
>
>         - Source Address      = FE80 0000 0000 0000 0201 4200 0000
>     0000 (elided)
>
>         - Destination Address = FE80 0000 0000 0000 0214 7700 0000
>     0001 (elided)
>
>       - RPL routing header
>
>         - CmprI = 15
>
>         - CmprE = 9
>
>         - Addresses = FE80 0000 0000 0000 0214 7700 0000 0002, FE80
>     0000 0000 0000 0214 7700 0000 0003, FE80 0000 0000 0000 0200 0C00
>     0000 0004
>
>     IPv6 packet
>
>       - IPv6 packet header
>
>         - Hop limit = 65 (elided)
>
>         - Source Address      = FE80 0000 0000 0000 0201 4200 0000
>     0000 (elided)
>
>         - Destination Address = FE80 0000 0000 0000 0214 7700 0000
>     0002 (elided)
>
>       - RPL routing header
>
>         - CmprI = 15
>
>         - CmprE = 9
>
>         - Addresses = FE80 0000 0000 0000 0214 7700 1234 0001, FE80
>     0000 0000 0000 0214 7700 1234 0003, FE80 0000 0000 0000 0201 42AB
>     CDEF 0004
>
>     IPv6 packet
>
>       - IPv6 packet header
>
>         - Hop limit = 64 (in line)
>
>         - Source Address      = FE80 0000 0000 0000 0201 4200 0000
>     0000 (elided)
>
>         - Destination Address = FE80 0000 0000 0000 0214 7700 0000
>     0003 (elided)
>
>       - RPL routing header
>
>         - CmprI = 9
>
>         - CmprE = 9
>
>         - Addresses = FE80 0000 0000 0000 0214 7700 1234 0001, FE80
>     0000 0000 0000 0214 7700 0000 0002, FE80 0000 0000 0000 0201 42AB
>     CDEF 0004
>
>     IPv6 packet
>
>       - IPv6 packet header
>
>         - Hop limit = 63 (elided)
>
>         - Source Address      = FE80 0000 0000 0000 0201 4200 0000
>     0000 (elided)
>
>         - Destination Address = FE80 0000 0000 0000 0200 0C00 0000
>     0004 (elided)
>
>       - RPL routing header
>
>         - CmprI = 9
>
>         - CmprE = 9
>
>         - Addresses = FE80 0000 0000 0000 0214 7700 1234 0001, FE80
>     0000 0000 0000 0214 7700 0000 0002, FE80 0000 0000 0000 0214 7700
>     0000 0003
>
>     Regards,
>
>     Michel
>
>     *From:* Pascal Thubert (pthubert) <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Monday, January 21, 2019 6:58 AM
>     *To:* Michel Veillette <[e-mail]
>     <mailto:[e-mail]>>; Dario Tedeschi
>     ([e-mail] <mailto:[e-mail]>) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: draft-ietf-6lo-fragment-recovery maximum fragment
>     size too small
>
>     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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* jeudi 17 janvier 2019 18:56
>     *To:* Pascal Thubert (pthubert) <[e-mail]
>     <mailto:[e-mail]>>; Dario Tedeschi ([e-mail]
>     <mailto:[e-mail]>) <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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)' <[e-mail]
>     <mailto:[e-mail]>>; Dario Tedeschi ([e-mail]
>     <mailto:[e-mail]>) <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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) <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Wednesday, January 16, 2019 9:59 AM
>     *To:* Michel Veillette <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* mardi 15 janvier 2019 20:14
>     *To:* Pascal Thubert (pthubert) <[e-mail]
>     <mailto:[e-mail]>>
>     *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) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *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
>