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

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2014 06:05:23 -1000

On 14 Nov 2014, at 05:46, Robert Cragie <[email-masked]> wrote:
> 
> Question - any reason the value 010001XY was chosen for the escape code?

Note that the escape space is not taken just for RFC 6553 compression; it can be used for encoding other NHCs as well.

The idea was to reserve some space around that so if we want to extend the escape space for some future NHC, we can do so while keeping it contiguous.

Note also that RFC 6282 already has variable length processing for hop limit and address compression, so the impact of adding a third instance is going to be limited.  (I need to write that up some more in draft-*-lwig-6lo.)

Since just about every data packet in a RPL network will carry an RPI, saving a single byte is worth quite some effort.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Nov 2014 15:46:26 +0000

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.

_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: [email-masked] [mailto:[email-masked]]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Robert Cragie <[email-masked]>
Date: Sun, 16 Nov 2014 01:42:04 +0000

Hi Carsten,

Comments inline.

Robert

> Note that the escape space is not taken just for RFC 6553 compression; it can be used for encoding other NHCs as well.
<RCC>Yes, I realise that one escape code can escape 2 bits of 
information from the succeeding NHC and that text for the NHC itself 
must describe how the preceding escape code(s) 2 bits are used. I think 
some extra explanatory text plus some guidance on choosing what data you 
might want to escape (i.e. that which is normally steady state and 
changes exceptionally) might help as it isn't immediately obvious.</RCC>
> The idea was to reserve some space around that so if we want to extend the escape space for some future NHC, we can do so while keeping it contiguous.
<RCC>OK, understood</RCC>
> Note also that RFC 6282 already has variable length processing for hop limit and address compression, so the impact of adding a third instance is going to be limited.  (I need to write that up some…
<RCC>I don't see any issue where the IPv6 packet is reassembled every 
hop. I was wondering if there might be an issue in the case of fragment 
forwarding although with RPL (i.e. route over), I am not sure if 
fragment forwarding is actually possible anyway, so it may not be an 
issue</RCC>
> Since just about every data packet in a RPL network will carry an RPI, saving a single byte is worth quite some effort.
<RCC>I don't disagree and if the consensus is that it is worth the extra 
processing then I have no objection. I realise "bits in the ether" in 
constrained networks are costly compared to the still fairly trivial 
extra processing for the escape.</RCC>