Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Philip Levis <pal@cs.stanford.edu> Wed, 30 July 2014 00:02 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFBC1B2A28; Tue, 29 Jul 2014 17:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 p9CpefRPLJkK; Tue, 29 Jul 2014 17:02:23 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B94A1A038D; Tue, 29 Jul 2014 17:02:23 -0700 (PDT)
Received: from [76.14.66.110] (port=55794 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XCHLY-0004Ah-A0; Tue, 29 Jul 2014 17:02:21 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com>
Date: Tue, 29 Jul 2014 17:02:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com>
To: Ines Robles <mariainesrobles@googlemail.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 1620fcb02ed1792cf65161168a9fe1e9
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Th2NnqLiNx1QJuyhHHqH7D2yefA
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Ole Troan <otroan@cisco.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jul 2014 00:02:27 -0000

On Jul 29, 2014, at 2:21 PM, Ines Robles <mariainesrobles@googlemail.com> wrote:

> Dear 6man and roll WGs,
> 
> We announce a joint Working Group Last Call for draft-thubert-6man-flow-label-for-rpl-03, since this document is related to both WGs, we ask for comments to 6man and roll members. We are going to request for an AD sponsored document.
> 
> This WGLC is going to take from 07/30/2014 to 08/13/2014.
> 
> Thank you very much,

I'm worried by the fundamental premise of the approach:

"The 8-octets overhead is detrimental to the LLN operation, in particular with regards to bandwidth and battery constraints.  The extra encapsulation may cause a containing frame to grow above maximum frame size, leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn cause even more energy spending and issues discussed in the LLN Fragment Forwarding and Recovery [I-D.thubert-6lo-forwarding-fragments]."

The basic assumption of this paragraph is that energy consumption is dominated by transmission time. Has anyone presented any actual evidence -- i.e., actual energy numbers -- of the cost this introduces? 

Because

"This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule."

makes the assumption that the energy saving is significant. Breaking the end-to-end nature of the flow label for some tiny saving seems like a mistake. But if this would actually save a significant amount of energy that couldn't be saved through other, simpler, means, then it seems like a great idea.

My fear is that this area -- low-power link layers, energy saving protocols -- is an area that is still new to the IETF and tends to have very subtle issues. What's being proposed here is pretty significant. Simple, intuitive arguments might not hold up to scrutiny in real networks.

If you look at it in this light, one comment the draft makes is especially troubling:

"But if we consider the whole RPL domain as a large virtual host from the standpoint of the rest of the Internet"

This is completely contrary to the deep, fundamental premise of the Internet of Things and when we started down the path of bringing IPv6 to LLNs. Before 6lowpan, LLN devices were typically considered peripherals, devices that connect to an Internet host through other interfaces and protocols (USB, ZWave, ZigBee, etc., etc.). This gave greater flexibility on what those networks could do, but it placed a hard barrier on the Internet. You needed new tools, management interfaces, software, and policies for managing the two sides of the network. E.g, you manage your IP network and separately manage your embedded network. The big promise of 6lowpan and all of the subsequent technologies the IETF has developed is that instead, we can consider it IP down into these networks as well. Considering an entire LLN as a virtual host goes back to this segmented model, and so is a step backwards.

In summary, this draft presents a tradeoff: break the end-to-end behavior of the flow label for improved energy efficiency. I'd argue strongly in favor of this draft if "improved" meant "doubles". But if it means "5% in 1% of use cases", this seems like a poor tradeoff. The IETF 90 slides say it's a "show stopper" for SDOs. I'm not sure what that means? Is there any greater detail on this? I'd like to make an informed engineering decision, but don't have enough data to do so.

Phil