[6tisch] Compression Reference and Coalescence

Tengfei Chang <tengfei.chang@gmail.com> Mon, 25 January 2016 11:00 UTC

Return-Path: <tengfei.chang@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C25DD1A8A0B; Mon, 25 Jan 2016 03:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q4EdAPzqgKsw; Mon, 25 Jan 2016 03:00:22 -0800 (PST)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 111661A8A08; Mon, 25 Jan 2016 03:00:22 -0800 (PST)
Received: by mail-yk0-x230.google.com with SMTP id k129so157206947yke.0; Mon, 25 Jan 2016 03:00:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yKvp0tOKXtivRoRhFwCurAL/BbkloeUywjSNIsuvoK0=; b=jcc3JezrJfuC9u+Q11ViN/SUsJWbz7/NIGsYHHRcqEP95rBwsdUipBxU3bMSpuLjU+ iw7ga2F3yMpoqhVgvJHAAKDskGRH/s31pNoDkwVqbWiyVfMFgoq+ayXIoj3GIFfqXwLI wWB6gt++AzPdGTHHE+xEw0KgDMcezHQu2v+5zbGv3zBDEEp3KPU08Cx9ZwqAMP7Dlhjr vXxRTScV4BuRK9/Gg1VYzYyeFv1INFLqbUV/iesAhZiE2X5sx1PSVlzvNDl6mL841XAI dQsRqZoJOdOyHi/SSVMJj16R1GylTLOW6BUDhe1HbDhVZlpoeNg5SrGWBxBU0llCOvXK avvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=yKvp0tOKXtivRoRhFwCurAL/BbkloeUywjSNIsuvoK0=; b=d9jT4QdfIZgGIYnJ1oi1VCjWSA+exMm4Vf4uqvRT006UW/oz3otOEKDHW6Sw3FkclP cLHfBaJggCAZ8BrP0MAH1FoV2Zsp6ZNP7gS0gixLfGmydk6cB6H83wrhuLW+oQXqg6UV HXLEIl+hkc6hEcPuvZqPOaG8Bbw3jY2HJDg/tZGMilZkYhOVRToQzOvIxw+anfRhIt8Z 1qKzm/CBbgifbb2Bv1W8I6aulGYIY8yeZUeol1ioI8w9dJjzebJFzHsE54rk1JQGsrQS CDgGfii1kad+tk8MrtHjPcRsQfkpbcGsxZJv+z7Zn8X4poPjVkvoqAPsOdgkf/G0+s7/ hFmg==
X-Gm-Message-State: AG10YOQm9LXAojs9m2cfafsbUyjSkUd9oAUD20OW+E0jU9ABrHaXzX+F1EEK6QA98jpYCoCEX/gFREBAx/AywA==
MIME-Version: 1.0
X-Received: by with SMTP id x66mr8042883ywd.229.1453719621356; Mon, 25 Jan 2016 03:00:21 -0800 (PST)
Received: by with HTTP; Mon, 25 Jan 2016 03:00:21 -0800 (PST)
Date: Mon, 25 Jan 2016 12:00:21 +0100
Message-ID: <CAAdgstTGw=YV0bAe60H1VLaA1ikKZX41OiQTKRPrXkEM3_LtfQ@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: "6tisch@ietf.org" <6tisch@ietf.org>, 6lo@ietf.org
Content-Type: multipart/alternative; boundary="001a114fa8e8a2565c052a267966"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/V9UOtdpr5N7Y_H23hSdWoOddDcc>
Subject: [6tisch] Compression Reference and Coalescence
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: Mon, 25 Jan 2016 11:00:23 -0000

Dear all,

I have some concern on the compression Reference and Coalescence.

In the 6lorh draft, all the hops in RH3 are compressed according to the
compression reference (the source address, root usually). And when doing
Coalescence, the process is kind of like taking the first address in first
RH3 as the reference. The inconsistency between compression reference and
Coalescense may waste some bytes in some cases.

For example:
A packet is issued by root with a compressed RH3 along an A->B->C->D
source route path.

The nodes address are:
root:      bbbb::0000:0000:0000:0001
node A: bbbb::1111:2222:3333:0001
node B: bbbb::1111:2222:3333:0002
node C: bbbb::1111:2222:3333:0003
node D: bbbb::1111:2222:3333:0004

According to the 6lorh draft: all hops in RH3 will be compressed according
to reference, which is the root. The  Packet received by node A is:

Type 3 RH3-6LoRH Size = 2  1111 2222 3333 0001
                                           1111 2222 3333 0002
                                           1111 2222 3333 0003

And which maybe more reasonable packet would be like :

Type 3 RH3-6LoRH Size = 0  1111 2222 3333 0001
Type 0 RH3-6LoRH Size = 1  02

Which means the first hop in first RH3 entry is compressed according to the
reference(which is the root in this case) and the rest hops are compressed
according to the first hop in first RH3 entry. For me, this compression way
is more consistent  with the way when doing coalescence.

What do you think?