[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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? 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 -- -------------------------------------------------+------------------------- 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/>
- [Roll] [6man] #5 (draft-thubert-6man-flow-label-f… 6man issue tracker
- Re: [Roll] [6man] #5 (draft-thubert-6man-flow-lab… 6man issue tracker
- Re: [Roll] [6man] #5 (draft-thubert-6man-flow-lab… 6man issue tracker