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

Robert Cragie <robert.cragie@gridmerge.com> Fri, 14 November 2014 15:46 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873B81A1A28; Fri, 14 Nov 2014 07:46:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6JQUisgoJtm; Fri, 14 Nov 2014 07:46:49 -0800 (PST)
Received: from mailscan1.extendcp.co.uk (mailscan12.extendcp.co.uk [79.170.45.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079AF1A1A04; Fri, 14 Nov 2014 07:46:49 -0800 (PST)
Received: from lb1.hi.local ([10.0.1.197] helo=mailscan2.extendcp.co.uk) by mailscan-g66.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XpJ5D-0008R5-JH; Fri, 14 Nov 2014 15:46:47 +0000
Received: from lb1.hi.local ([10.0.1.197] helo=mail41.extendcp.co.uk) by mailscan2.extendcp.co.uk with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1XpJ5A-0007ew-Gk; Fri, 14 Nov 2014 15:46:47 +0000
Received: from host31-51-175-12.range31-51.btcentralplus.com ([31.51.175.12] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1XpJ58-0008M9-Iq; Fri, 14 Nov 2014 15:46:43 +0000
Message-ID: <546623D2.4060207@gridmerge.com>
Date: Fri, 14 Nov 2014 15:46:26 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
References: <20141025070548.825.87046.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A1E80C@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD848A1E80C@xmb-rcd-x01.cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms090608090201060205060300"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/5bIrbAKwvAI4OyTW2yGFzu2xooc
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-rpl-nhc-02.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 15:46:52 -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.

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> 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
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>