Re: [6lowpan] [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt

Carsten Bormann <cabo@tzi.org> Thu, 19 May 2011 16:27 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15889E0720; Thu, 19 May 2011 09:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLQjgB-xt89V; Thu, 19 May 2011 09:27:05 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 19868E06E0; Thu, 19 May 2011 09:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4JGQtB8019659; Thu, 19 May 2011 18:26:55 +0200 (CEST)
Received: from [192.168.217.112] (p5B3E62ED.dip.t-dialin.net [91.62.98.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6143AE2B; Thu, 19 May 2011 18:26:55 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu>
Date: Thu, 19 May 2011 18:26:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C192F33D-AF22-40D8-9246-2F5C1B808946@tzi.org>
References: <419255340.364951.1305741570332.JavaMail.root@mail05.pantherlink.uwm.edu>
To: Mukul Goyal <mukul@UWM.EDU>
X-Mailer: Apple Mail (2.1084)
Cc: roll <roll@ietf.org>, 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] [Roll] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2011 16:27:06 -0000

Mukul,

I just looked at your draft in a little more detail.
Certainly, a purpose-built spec to squeeze out redundancy from a specific packet format will generally be more efficient than the generic compression I have written up.

However, the arguments in section 1.1 of draft-bormann-6lowpan-ghc-02.txt apply to the fullest here.
Since the HC spec needs to be understood by all nodes, it creates a powerful obstacle in evolving the subject protocol.  The strong coupling between the subject protocol and the compression spec also creates opportunity for interesting interoperability problems.

As a distant observer of the ROLL WG, one thing I don't understand is why this is necessary in the first place.
As far as I understand, the domain of RPL is low-power (i.e., constrained) networks.
6LoWPAN is just one of the network types RPL will be used on, and redoing this work for every other type (that benefits from compactness) sounds wasteful to me.
Why doesn't RPL itself define a reasonably compact representation then?

Gruesse, Carsten