Re: [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt

[Robert Cragie <[e-mail]>]

Hi Pascal,

First of all, thanks to all the contributors to this work in producing 
this draft expediently.

My opinions on the approaches:

_Greedy_

Unacceptable to grab such a large portion of the NHC space. It sets the 
wrong precedent and limits future enhancements.

_Conservative_

This is the most consistent with RFC6282 and current processing in that 
it add the occurrence of a single NHC type to indicate the presence of 
RPI_NHC compressed header. The one downside is that it uses one of the 
two remaining options in the standard NHC encoding. So whilst this only 
grabs 1/256 of the space, it only leaves one further possible use. 
Furthermore, RPI_NHC is not actually an IPv6 Extension Header, it simply 
represents an option in a Hop-by-Hop Options header. The compression 
applied to RPI_NHC highly specific unlike the general compression 
applied to an IPv6 Extension Header and therefore the RPI_NHC would 
require a specific case in NHC compression and decompression.

One possible alternative to consider might be to allocate a new type of 
NHC; let's call it Specific LOWPAN_NHC:

                       0   1   2   3   4   5   6   7
                      +---+---+---+---+---+---+---+---+
                      | 1 | 1 | 0 | 1 |    EID    |NH |
                      +---+---+---+---+---+---+---+---+

    EID: Specifically compressed header ID:

       0: Compressed RPL Option (RPI_NHC) [RFCthis]

This could go into RFC6282 as such with the text that the defining RFC 
MUST explain the compression and decompression mechanism.

The obvious disadvantage is that it takes a larger portion of the NHC 
space (1/32) but it makes actual NHC processing more straightforward.

_Efficient_

It is clear that in normal cases, it is as efficient as the greedy 
approach. Whilst the RPI_NHC option occupies 1/4 of the space of the 
greedy option (i.e. 1/16, which is still quite a bit), the escape option 
occupies another 1/64 of the space. However, occurrence of the escape 
code complicates processing. Moreover (and I know this has been 
discussed before), the length of the overall compressed option can 
change from hop to hop, which it won't do in the case where the normal 
Hop-by-Hop Options header is used.

Question - any reason the value 010001XY was chosen for the escape code?

_Conclusion_

Firstly, greedy is out for me - it grabs too much space.

If the overriding requirement is to save as many bytes as possible, the 
efficient approach would be the best choice. It is not clear to me 
whether the possible length changing has any implications but it could 
clearly cause fragmentation, which seems undesirable, especially if 
mechanisms to forward indivdual fragments are being considered.

I think the cost of having one byte for the extra NHC is not a huge cost 
and provides consistent packet sizing therefore I favour the 
conservative approach. I would also possibly consider the remarks made 
regarding the different type of subsequent header.

Robert

On 25/10/2014 8:35 AM, Pascal Thubert (pthubert) wrote:
> Dear all:
>
> We have converged for most of the design of the 6lo compression for the RPL packet information and republished.
> A major question is left on the table for the working group, and isolated in section 4.3, with 3 approaches proposed.
>
>       4.3.  The RPI_NHC encoding  . . . . . . . . . . . . . . . . . .   5
>         4.3.1.  The Greedy Approach . . . . . . . . . . . . . . . . .   7
>         4.3.2.  The Conservative Approach . . . . . . . . . . . . . .   7
>         4.3.3.  The Efficient Approach  . . . . . . . . . . . . . . .   8
>
> Your review prior to the IETF meeting will be appreciated more than ever.
> At the 6lo meeting, we expect to have a slot and obtain a rough consensus of the room on that particular question.
> We will also call for adoption.
>
> Finally, there seems to be a will to propose a compression for the Routing Header as uses in RPL non-storing mode, and hopefully we will see proposals soon.
>
> Cheers,
>
> Pascal
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: samedi 25 octobre 2014 09:06
> To: Carsten Bormann; Dr. Carsten Bormann; Pascal Thubert (pthubert); Pascal Thubert (pthubert)
> Subject: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt
>
>
> A new version of I-D, draft-thubert-6lo-rpl-nhc-02.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository.
>
> Name:		draft-thubert-6lo-rpl-nhc
> Revision:	02
> Title:		A compression mechanism for the RPL option
> Document date:	2014-10-24
> Group:		Individual Submission
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-thubert-6lo-rpl-nhc-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-rpl-nhc/
> Htmlized:       http://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-rpl-nhc-02
>
> Abstract:
>     This specification defines the RPL Packet Information (RPI) NHC
>     compression, a method to compress RPL Option (RFC6553) information
>     within 6LoWPAN-style ("6lo") adaptation layers.  This extends 6LoWPAN
>     Header Compression (RFC6282), saving up to 48 bits in each frame
>     compared to the uncompressed form in RFC 6553.
>
>                                                                                    
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>