Re: [6tisch] [6lo] Compression Reference and Coalescence

Tengfei Chang <tengfei.chang@gmail.com> Tue, 26 January 2016 16:56 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7071B2CCE; Tue, 26 Jan 2016 08:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaXAz-MtRt0F; Tue, 26 Jan 2016 08:56:26 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 5573E1B2B29; Tue, 26 Jan 2016 08:56:26 -0800 (PST)
Received: by mail-yk0-x236.google.com with SMTP id v14so206903315ykd.3; Tue, 26 Jan 2016 08:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6s5OGDc4A8yw/z2wNKSXCgx2nq3L1WTTSKdlrv545ME=; b=us39zP8nJDg7XIqxmqRnIiRQHou+ik+C0zi7eAuBZVNzLIaKsFKlaRmYNDP/wLbSZC zUWrZn/Y7fHQvRIkXOraqk3xYIdYr29vpSGEIjB6Kn10A3aTqMQOd8wEQvHUOYIp7Lp7 ZQlbnvMGf67yFSuPCC9KyhfIobfws870NlCVkoHFddsefRpmRdRLKTKnO7v7LCQ1jptc KvOoeDJ5XNChH5yO74+j2jtvsxa1t7Q03xzoxFG/guzyP6h0QFpArPf2PMyWC59/CjTX LuRPF1BXq6qDyA3O9thRnlUeV43+xyqcI+5ZJUsFWccciPKGGkc7xxidtMqbh8um0m9e oC7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6s5OGDc4A8yw/z2wNKSXCgx2nq3L1WTTSKdlrv545ME=; b=klTy6ABm0+pWspCpSMdBhYiRIVPl7GuDwp4UJqYQlJAefiZ44Bqas0OYXwfsUAFN1i BfC/E89gAClk7tmd5Lt2K/gWtEnzERut9BUuCo1zTlEUOnNmiQAmisGpo9NP6nTIE+er 92veBG3YUPkVzPGla0PVmFH3WkEDg+1lzSFMetv8TRtxD4eApGcNxtaA5SPz1bvYreIW plK2jQiQvt5/qr0tr/GPqG+i+ThKto8wkX2hxUou3Jg9ZZkGgGPsQJmMYi6o1WX4zHIn D/et1d/t1jJXBVLspZSu0IgY+Cj7HwlKgCIkVnsNrc7MbGzr1dLTOCbbQ0osty0jCagF vBrA==
X-Gm-Message-State: AG10YOSwxNFJNGwU1/rsk8afVnBMkZwfPFLbWHHnJsITW9BeAFTHvfM7vHGcFDNF4vg4FUczsl/JbQFcQ94L+Q==
MIME-Version: 1.0
X-Received: by 10.13.210.7 with SMTP id u7mr11882644ywd.100.1453827385592; Tue, 26 Jan 2016 08:56:25 -0800 (PST)
Received: by 10.37.201.5 with HTTP; Tue, 26 Jan 2016 08:56:25 -0800 (PST)
In-Reply-To: <078cb52ea1904304b32f2936e24e19a4@XCH-RCD-001.cisco.com>
References: <CAAdgstTGw=YV0bAe60H1VLaA1ikKZX41OiQTKRPrXkEM3_LtfQ@mail.gmail.com> <078cb52ea1904304b32f2936e24e19a4@XCH-RCD-001.cisco.com>
Date: Tue, 26 Jan 2016 17:56:25 +0100
Message-ID: <CAAdgstTQcg5gHbrgy5RABVK9oHRzYY8XpTXBrkHUs0ShvR3TvQ@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=001a114e7e78e21119052a3f901c
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/o0Hv8R7jS_vCLtKddH0KrJ75ZWE>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6tisch] [6lo] 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: Tue, 26 Jan 2016 16:56:29 -0000

Nice to hear that's what you intended to do!

In  the beginning of section 4.3:
...

   Once the address of the source of the packet is determined, it
   becomes the reference for the compression of the addresses that are
   located in compressed RH3 headers that are present inside the IP-in-
   IP encapsulation in the uncompressed form.

...


When I am understanding the sentence, I am feeling like all the compression
of addresses in RH3 will be compressed according to source address in
IPinIP, which only the first 8 bytes can be elided.

If agree with the reasonable one, it should be the first address in first
RH3 is compressed according to the source address in IPinIP.
Then, all rest address in RH3 will be compressed according to the first
address in RH3.

Make sense?
Tengfei

On Tue, Jan 26, 2016 at 5:23 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Tengfei:
>
>
>
> The draft is meant to express exactly what your reasonable case shows.
>
> There is an example of that in appendix.
>
> What exactly did I write improperly that it can be understood otherwise?
>
>
>
> Take care ;
>
>
>
> Pascal
>
>
>
> *From:* 6lo [mailto:6lo-bounces@ietf.org] *On Behalf Of *Tengfei Chang
> *Sent:* lundi 25 janvier 2016 12:00
> *To:* 6tisch@ietf.org; 6lo@ietf.org
> *Subject:* [6lo] Compression Reference and Coalescence
>
>
>
> 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
>                                             03
>
> 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?
>
> Tengfei
>