[Roll] [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption

"6man issue tracker" <trac+6man@trac.tools.ietf.org> Sun, 10 August 2014 16:48 UTC

Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C967A1A07A2; Sun, 10 Aug 2014 09:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IbgRt-3lZIF0; Sun, 10 Aug 2014 09:48:32 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 9D80A1A0470; Sun, 10 Aug 2014 09:48:32 -0700 (PDT)
Received: from localhost ([::1]:57692 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XGWIH-0002t1-PF; Sun, 10 Aug 2014 09:48:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Sun, 10 Aug 2014 16:48:29 -0000
X-URL: http://tools.ietf.org/wg/6man/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/5
Message-ID: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 5
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZrU2LJcC8lBLx-sHS9loY5JDRgY
X-Mailman-Approved-At: Sun, 10 Aug 2014 09:52:02 -0700
Cc: roll@ietf.org, 6man@ietf.org
Subject: [Roll] [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org, 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: Sun, 10 Aug 2014 16:48:33 -0000

#5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08755.html

 From: Philip Levis <pal at cs.stanford.edu> Date: Tue, 29 Jul 2014
 17:02:17 -0700

 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?


 "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

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

 "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.


 Reporter:  mariainesrobles@gmail.com            |      Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |     Status:  new
Component:  draft-thubert-6man-flow-label-for-   |  Milestone:
  rpl                                            |    Version:
 Severity:  In WG Last Call                      |   Keywords:

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/5>
6man <http://tools.ietf.org/wg/6man/>