Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 19 January 2016 21:10 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BFE1B3179; Tue, 19 Jan 2016 13:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 GlJrYgAIU6As; Tue, 19 Jan 2016 13:10:37 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD721B360F; Tue, 19 Jan 2016 13:10:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1453237837; x=1454447437; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XPhIm8ygEa4jCTkk6CDXxMG56mvx56YHXIxNcqrZai4=; b=bPSntnb5+pStfTbuwTWJ/mj4btHvh/Koocuxa8FffAjZwddEAKoArBOX CUDAOweuGrR6Mc9/KHF1EHuwonCV/09FuBFasrjTjA+tjipozQKftBZgY v1kxGG23tbkk+dmdEaiwpXUmN0Zby6A5IqXeNAWrXMVX+90ra0XaIkb3j U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgAMpZ5W/4cNJK1egzqBPwaIULJvA?= =?us-ascii?q?Q2BY4JfgzACHIEpOBQBAQEBAQEBgQqENAEBAQQjEUUMBAIBCBEEAQEBAgIjAwI?= =?us-ascii?q?CAh8RFAEICAIEAQ0FCId+AxKwKYwKDYNMAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?XuFP4R0gk6BZ4MzgUkFlxoBi2aBcYFljSOGf4Ntg28BIAEBQoQJcoVmgQgBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,319,1449532800"; d="scan'208";a="65031435"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2016 21:10:36 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0JLAalA016195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jan 2016 21:10:36 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jan 2016 15:10:35 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Tue, 19 Jan 2016 15:10:35 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Simon Duquennoy <simonduq@sics.se>, Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
Thread-Index: AQHRUvuffhFpFTuUWEKxbjcV3WJQGp8DUlQQ
Date: Tue, 19 Jan 2016 21:10:30 +0000
Deferred-Delivery: Tue, 19 Jan 2016 21:10:14 +0000
Message-ID: <3e6743161cd94977bfb8d8ec76cd4a83@XCH-RCD-001.cisco.com>
References: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com> <CAAdgstQXj80Pu-Syt_QuxD4_8V0PqEZqxVDsnyGdbBA-hGxEKQ@mail.gmail.com> <2c372ed593ad4d12a7ffff81c3ada270@XCH-RCD-001.cisco.com> <CAAdgstSiochR48+XVV3wCScd_XEttO0Us3rWNu=XVsO8_=kw2A@mail.gmail.com> <CAMxvJtLCN_6+NPruYu5J5KHOybbu+PdDeod7V8S+_iZTKhZTCg@mail.gmail.com> <1ebd8224c530495eba190b8b71f633f6@XCH-RCD-001.cisco.com> <CAMxvJtJ0F_SYe023Bv0y6DixTSQi=PTaKd56ECZdrrrXBk3ApA@mail.gmail.com> <2416.1453235644@obiwan.sandelman.ca> <CAMxvJtJ5ZR_fMh3KvH_yePwEaWKBDNaD4+SnO-W=vDf97Uru-Q@mail.gmail.com>
In-Reply-To: <CAMxvJtJ5ZR_fMh3KvH_yePwEaWKBDNaD4+SnO-W=vDf97Uru-Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/GcBUHRcA0GMGlyKr6TPX4Q_7p1w>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Tengfei Chang <tengfei.chang@gmail.com>
Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2016 21:10:39 -0000

Hello Simon:

Could we take some examples? If possible most of them reasonably realistic? We"ll see the outpout of both methods. 

Again I have nothing against allowing the precision of the byte in the compression, but then is that a real world problem worth wasting types in the 6LoRH? I'd think not for the first 6 actets of the prefix.

I agree with you for the goal
"
Any level of awareness is too much, IMO a RPL implementation should run
unmodified yet benefit from 6LoRH.
"
But the draft does not achieve it as you prescribe. 

The 6LoRH is designed to enable the insertion of a RH3, the addition a RPI, or the IP in IP encapsulation, or any combitnation thereof, without changing a bit in the packet encoded with RFC 6282 (with the restrictive assumption that the RPL artifacts are always encoded with 6LoRH).

I think there is value in:
- preserving the RFC6282 handlers without a change
- manipulating easily the headers induced by RPL without touching the original packet and in particular without the swap of destination address with RH.

Isn't that worht something?

Pascal

> -----Original Message-----
> From: simon.duquennoy@gmail.com [mailto:simon.duquennoy@gmail.com]
> On Behalf Of Simon Duquennoy
> Sent: mardi 19 janvier 2016 21:55
> To: Michael Richardson <mcr+ietf@sandelman.ca>
> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; 6tisch@ietf.org;
> Routing Over Low power and Lossy networks <roll@ietf.org>rg>; Tengfei Chang
> <tengfei.chang@gmail.com>om>; 6lo@ietf.org
> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
> 
> Any level of awareness is too much, IMO a RPL implementation should run
> unmodified yet benefit from 6LoRH.
> For instance, if RPL produces a RH3 with cmpri of 6 and cmpre of 10, we end
> up with two RH3-6LoRH, each with its own "size unit", which has to be
> power of two -- we end up with a compressed possibly larger than the
> original.
> Another example is when more than two RH3-6LoRH are included to benefit
> from a variety of compression levels: in such case, it is not even possible to
> translate the compressed back into a standard RH3.
> 
> Generally speaking 6lowpan offers one-to-one mappings between
> compressed and original headers, I think it is a pity that 6LoRH doesn't.
> 
> On Tue, Jan 19, 2016 at 9:34 PM, Michael Richardson
> <mcr+ietf@sandelman.ca> wrote:
> >
> > Simon Duquennoy <simonduq@sics.se> wrote:
> >     > I feel we need to make sure any valid RH3 can be compressed with
> 6LoRH. This
> >     > way, RPL implementations do not need to be aware of 6LoRH.
> >
> > I'm sensitive to your need, but I'm not sure it's worthwhile.
> >
> > What kind of awareness do you feel is required?
> > There needs to be some communication of what are the interesting
> prefixes.
> > I don't see this as a problem.
> >
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software
> Works
> > -= IPv6 IoT consulting =-
> >
> >
> >