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

Simon Duquennoy <simonduq@sics.se> Tue, 19 January 2016 21:39 UTC

Return-Path: <simon.duquennoy@gmail.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 8BCC01B369D; Tue, 19 Jan 2016 13:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 R_LkbyQV3DaL; Tue, 19 Jan 2016 13:39:40 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5571A00F5; Tue, 19 Jan 2016 13:39:39 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id r129so107829357wmr.0; Tue, 19 Jan 2016 13:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OwYMhoVa9v3RT6JElSVb69MKQuj9/lK8KKc3jOZ/Y5g=; b=JyC20jClF5NzqiDmCNZS+mJnNyctgYQL4nkowMPPQSlWshf2+U3ff5rEgO2rsRHUOf 9TjEAiTQcHA+oUzxwqT66UFnFGw7BPNKAzd+IY+TL8IH6DIJNV6D2a7ycd6J2H5Awp4q i2Tr1XtO7muVhCw30RRdNnD7mBpJ3tvR3yaj0wqvvCw2mraYgsvRi1Pkt4g5cvq2ekl+ RJb4mIUPiCDOiHi7+l9b9STr+SBADC1sxxBtkn8Me9IuPx6RvFCSSJ6jH/w9/ztwi8Jr 6gFb12lwKsAE1gkYc6+/E/ccCCmi3KicmsiZQhD85gqEG7IPFUd98DWxlTum7jCBNAZN 9odg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=OwYMhoVa9v3RT6JElSVb69MKQuj9/lK8KKc3jOZ/Y5g=; b=dScklccCrYBqW6Y/K9tBa1Gx6pC5D9+3rBvOJ82geIVHTem2GiL7gIqzBuVi5KeorW pbgAKyuZGnqzTHfhi2RDktigL8TQyL4FKNPjIp3V0CrUuHOHbbCc/2l8CUCPvcU9fm7y bVbyqFRxQaK2hYlRRZNiyJeei6mehhZPz8onQrnp3pzbkghUozV1Ll6Y8ZE/l0vXUSzX fq3uxxq+uAtM+LlTmfQRh7pXglozmwiw2/TtZTWOQOJuz1SctdautfHITQkLEG36oCJw AnQN8TKGs5+qRUaQHQVktEKtk1luC0A3vIq4ynyQtgoRskrkj6RtP5fixpCshJQR1hLW XMhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OwYMhoVa9v3RT6JElSVb69MKQuj9/lK8KKc3jOZ/Y5g=; b=AgP09g8WZdkMU39m0MfSlu9ZtP5n3GCXtLkLX4U9BOhtzVIXu2vDy6jFH9DqM4KMXr D10IDDt0E18FcTDuBkhyHSxxa7OiBY0aAFfoy2MkNJ1ba4n0msH6//VFqTiPB0+pKE0k 5o95bzS8Wqc+XTw5Gnx8Wf+ew9+4xy9Z/NOB2aKun8VFSjzZzGJNPXrccn5wuNpl9158 fIZZ6v9hL8EXyk9BpGmDylVxG5ml78hidHV7J72gHIufBh5VMmIfN8WtGiF8iOsBHxf2 8X3Q9h8VBmYHgTffuWkU/qYhlsUlzC4KjmgffGyKMHwJbVJu0nB8kiTQ0+EzDYTtbrS9 Dc6w==
X-Gm-Message-State: ALoCoQnj46gBA6aCbqCQ8l5sPxObXqKxc0ELLIqUB91MdAxXuGezcljLSVXg+KIEolRLCeWiicOXR6bK3gSWCO9bibVu+ka2eQ==
MIME-Version: 1.0
X-Received: by 10.194.63.40 with SMTP id d8mr32203089wjs.127.1453239578308; Tue, 19 Jan 2016 13:39:38 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.194.79.97 with HTTP; Tue, 19 Jan 2016 13:39:38 -0800 (PST)
In-Reply-To: <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> <3e6743161cd94977bfb8d8ec76cd4a83@XCH-RCD-001.cisco.com>
Date: Tue, 19 Jan 2016 22:39:38 +0100
X-Google-Sender-Auth: dZL0FAENo9NZK1RvqndMcUaSPFs
Message-ID: <CAMxvJtL+fcmYqLDmFeWMRT1kFfqTHLQ3Xs0eoo1TdNqBdKBsSA@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/UZZazWPdVYsTRtxnw2ecDsW7Kdo>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "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:39:41 -0000

On Tue, Jan 19, 2016 at 10:10 PM, Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
> 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.

OK the effectiveness of the compression wasn't my main concern anyway,
it was rather on the mapping between RH3 and RH3-6LoRH.

>
> 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?

Yes I see much value in both the above!
But I feel these goals could equally be achieved with simple
compression of the standard RH3 header, rather than a redesign.
I'm mostly worried about the fact that RPL implementations will have
to produce 6LoRH headers, i.e. be 6lowpan-specific and play with
6lowpan compression from a layer above.

BTW the new text you suggested above makes sense to me, it does clarify things.

Thanks,
Simon

>
> 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 =-
>> >
>> >
>> >