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

Simon Duquennoy <simonduq@sics.se> Tue, 19 January 2016 19:32 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 199D51B34E4; Tue, 19 Jan 2016 11:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level:
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 kbF3CBv-UjHv; Tue, 19 Jan 2016 11:32:13 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 88AD31B34DF; Tue, 19 Jan 2016 11:32:11 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id 123so105336422wmz.0; Tue, 19 Jan 2016 11:32:11 -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; bh=LX163qdRVGYDvtF1DjpTODWSgEs/M22CimXR5demidk=; b=sbuFPaBBTBI6HUOHaq7P7Q2OGxzDdXlnbTZUjDotW3oG7VHkRR3wZ7i/WkBSW9aC/+ W+VvcaXZWbWC2mwwmT2RbCKXQgvl3ltwhI8QjOS53mRMUoKl9tb7MWAiwHwabaTEbxRm rIgQlt+9UFKjlmaqDc9H0AHmL/kSLdW5axSJW11QJB7Io8WWGAxJwN3BY5WLZkgiFOs0 i1f7f2TdT9hkNXiy5l745GBKyrzBlzt8XASfOSLrgAMyRfcFkSclR41Quzm1/q27n8ZV oJej8udnibsoMIqYQyoFWKKxP3XujvgqO3AOnOI9xRxOdj9UXMWSQ07hYBpn3NN0fo2D Q1Ew==
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; bh=LX163qdRVGYDvtF1DjpTODWSgEs/M22CimXR5demidk=; b=c6olOtNetts/5NL6yIZtDVJXKK+RX9MtkaMJYXbD8OWdw4hrl0Y/YjeKXZUFSywb7H rDy1nTbc3z2kVql3WcdDY81gLXyQmoDbGFuO7kkOyeVM0AF5sGWKMF3soXiVDsif3A/2 bwpY+K1QgasDqSZlenw6LW7RPXGqjNSuaTqhr1k1MAenKSdMg1DQL5L6/JK44U1k5k9q evzFKnzv9o8FSZNzUZDGmIq0RPJJgb/uZJ6fWCqEZBtM9yX0cuEHET1HnVsH4tlEGgkB nh6lnUScl8fbeZVQ1E8WN4iqDCLS/ZE0gvn1/XRmHDXb6r8g/SkY9VTztHUZiHRl36VX dYBA==
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; bh=LX163qdRVGYDvtF1DjpTODWSgEs/M22CimXR5demidk=; b=TFY65wDZsL3X0RcOEkbD+XlQ0wUqXYnWBiJgYePexgfOi2DFjhKcI/+gAh1TFsuby7 rXjYqkDiQZyG9Xzttx+LDN9oWZGHhz4QqyDvNaSROeQNfK5PEbfwrPyDzrpu32CeBazB jKbNCIl5rnypFIXBrsOu7Wsv2DSWtXGdkUvqm1wIA1Dk9QXs4fz8hIInG/GgY0akcoKP v7X4K3ffA1SlixEuxxVihcmcYmrMCJBXAilN8RWDIgjtIkNGsQnlj5F9Tq6qf9D5IVl9 iTDTxSYlAOikIEnZzSl7FYuzMH9r0d5xCMzbkE7ChdpstkkfrTqeGQzOkZ0y3SvvPy75 H6SQ==
X-Gm-Message-State: ALoCoQkoQ70CKS6Exrwys/hmnlp565ixqjNHTbmsvCfDe/Db4+qVS77qr2EdPVwkbjkFKK/WBV+49ljuchO7VQukcERxpHrkPw==
MIME-Version: 1.0
X-Received: by 10.194.95.34 with SMTP id dh2mr30848447wjb.63.1453231930015; Tue, 19 Jan 2016 11:32:10 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.194.79.97 with HTTP; Tue, 19 Jan 2016 11:32:09 -0800 (PST)
In-Reply-To: <1ebd8224c530495eba190b8b71f633f6@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>
Date: Tue, 19 Jan 2016 20:32:09 +0100
X-Google-Sender-Auth: 2gHwQ1HmZ7nORN3lDN9imbsG6pc
Message-ID: <CAMxvJtJ0F_SYe023Bv0y6DixTSQi=PTaKd56ECZdrrrXBk3ApA@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/related; boundary=047d7bb04a8cf7557c0529b4ec29
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/SmDvJIPjARB_oGYVTAHjk8cE8R8>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Tengfei Chang <tengfei.chang@gmail.com>, "6lo@ietf.org" <6lo@ietf.org>
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 19:32:16 -0000

Hi Pascal,

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.
For the compression level, we could maybe optionally carry a full value
inline (or well, it's only 4 bits..).
As for using the root's address as reference for compression, although the
idea makes sense, I'm afraid it makes it complicated to compress RH3, where
the prefix is copied from the IPv6 destination.

Thanks,
Simon


On Tue, Jan 19, 2016 at 8:15 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Simon:
>
>
>
> You can get different cmpri and cmpre values, by placing 2 different
> RH3-6LoRH header. Having as many 6LoRH headers allows you to compress that
> even more, like having intermediate cmprx values should you need that.
>
>
>
> But ultimately what we compress is the RH0 format with the rules of RH3,
> knowing that apart from the rules RH3 is just a compression of RH0.
>
>
>
> And then 6LoRH can enable a better compression when coalescing from the
> root’s address.
>
>
>
> I agree that we placed an artificial limit with the power of 2, to avoid
> consuming too much type space. But if the power of 2 does not much the real
> world use cases and needs, now is a good time to change it.
>
>
>
> Do you have an opinion on that?
>
>
>
> Pascal
>
>
>
> *From:* simon.duquennoy@gmail.com [mailto:simon.duquennoy@gmail.com] *On
> Behalf Of *Simon Duquennoy
> *Sent:* mardi 19 janvier 2016 18:53
> *To:* Tengfei Chang <tengfei.chang@gmail.com>
> *Cc:* Pascal Thubert (pthubert) <pthubert@cisco.com>om>; 6tisch@ietf.org;
> Routing Over Low power and Lossy networks <roll@ietf.org>rg>; 6lo@ietf.org
> *Subject:* Re: [6lo] [6tisch] Proposed improvement in RH3-6LoRH
>
>
>
> Hi Pascal,
>
>
>
> One thing that bugs me is that RH3-6LoRH seems to be an alternative to RH3
> rather than a strict compression of it. For instance, a RH3 using different
> cmpri and cmpre values, or using non power-of-two, can not be compressed
> with 6LoRH. And the discussion on copying the prefix form the DAG root is
> also a departure from RH3.
>
> Am I missing something?
>
>
>
> Thanks,
>
> Simon
>
>
>
>
>
> On Tue, Jan 19, 2016 at 1:59 PM, Tengfei Chang <tengfei.chang@gmail.com>
> wrote:
>
> Hello Pascal,
>
>
>
> Thanks a lot for the detailed answer! I think it solves all my concern. I
> will vote for it!
>
>
>
> Tengfei
>
>
>
>
>
>
>
> On Tue, Jan 19, 2016 at 11:00 AM, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
> Hello Tengfei:
>
>
>
> Basically the change proposal accounts for the assumption that the last
> segment may be different, which comes with the idea of supporting non RPL
> leaves. If you look at it the original RH4 (RFC 6554) makes a difference
> for the last hop.
>
>
>
> Also, the root is the one computing the 6LoRH so it is easier for it to
> take its own address as reference.
>
>
>
> Finally the text is unclear about which bits from the destination are to
> be used.
>
>
>
> All in all, using the root as reference makes more sense than using the
> final destination as I had initially proposed. So the new proposal is not a
> merge but an instead, with clarifying text about the process I showed in
> the picture.
>
>
>
> More answers  inline:
>
> Dear all
>
>
>
> The picture below illustrates how the RH3 6LoRH works with draft 03 in a
> case like Root -> A -> B -> C -> leaf
>
>
>
> [image: cid:image001.png@01D152A0.1C780E10]
>
>
>
> The first 6LoRH is expected to be a full address (128 bits) to set up a
> reference and the next 6LoRH are expected to be smaller and just override
> the rightmost bits which form the delta from the reference.
>
>
>
> What if the B and C address can be compressed to one byte(RH3-6LoRH type
> 0)?
>
> When leaving the root the format would like:
>
> *RH3-6LoRH type 4    IPv6 Prefix (64bits)   A's suffix (64bits)
>  RH3-6LoRH type 0      B's suffix (8bits)    C's suffix (8bits)*
>
>
>
> Ø  Pascal If A’s address is the same as B and C for the first 120 bits
> then this format is correct : )> Pascal
>
>
>
>
>
>
>
> should node A need to extend the address of B address when the packet
> leaving A? Like:
>
> *RH3-6LoRH type 4    IPv6 Prefix (64bits)   B's suffix (64bits)
>  RH3-6LoRH type 0      C's suffix (8bits)*
>
>
>
> Ø  Pascal: That is correct. Note that there is no separation between
> prefix in suffix in the type 4. So the drawing applies for all types if you
> consider that the prefix length is 64, 96, 112 or 120 depending on the type
> of the next RH. With the proposal, if the root has the same /120 prefix as
> A, B and C then we have a single type 0 with A, B and C in it.
>
> Proposal: we could consider that the 128bits source of the IP header
> before the RH3 is the reference to start with.
>
> I have no comments with the proposal. Just want to mention in the
> currently version of draft (version 3) , it says : (in section 5)
>
> ...
>
>    If some bits of the first address in the RH3-6LoRH header can be
>
>    derived from the final destination in the LoWPAN_IPHC, then that
>
>    address may be compressed; otherwise it is expressed as a full IPv6
>
>    address of 128 bits.  Next addresses only need to express the delta
>
>    from the previous address.
>
> ...
>
> How to understand this combining with the proposal? (Or this is the point
> we are going to replace by the proposal? Let me know)
>
>
>
> Ø  Pascal: proposal is to replace. That text was unclear and more complex
> to implement.  And fails to optimize for leaves that are not configured
> like the mesh.
>
> With that even the first hop could be compressed the same way as the other
> hops. With RPL, the root is the encapsulator if IP in IP in used. Good
> thing, in that case the root is totally elided with the IP-in-IP 6LoRH.
>
> That's great! Could I confirm when the packet is inside a RPL domain where
> IP in IP is elided, the source destination in IPHC is the reference?
>
> Ø  Pascal: Yes. The only case where IP in IP is elided is when the source
> is the root. The root would still be the reference. The text I proposed
> says the Source of the header that is placed before the RH3, and I meant in
> the non-compressed form. With RPL as it stands today this is always the
> root.
>
> So this simple proposal saves up to 16 octets (that’s in the case with a
> single subnet and all addresses differ only by the last 2 bytes). I’m
> willing to add it in the next revision.
>
> I don't know how to calculate the saved bytes. For this case, will the
> format looks like this?
>
> RH3-6LoRH type 1    A's suffix (16bits)     B's suffix (16bits)   C's
> suffix (16bits)
>
> Ø  Pascal: Yes. In that case you save 14 bytes in A’s address plus the
> RH3-6LoRH type 4 which is 2 additional bytes, 16 total.
>
> Any opposition?
>
>
>
> Pascal
>
>
>
> Thanks for the proposal!
>
>
>
>
>
> Ø  Pascal: Do you vote for it? I’m asking because the plugtest is coming.
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>
>