Re: [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:50 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 C37B21A07AE; Sun, 10 Aug 2014 09:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level:
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 m0clkZqS6Lw7; Sun, 10 Aug 2014 09:50:45 -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 A912E1A0465; Sun, 10 Aug 2014 09:50:45 -0700 (PDT)
Received: from localhost ([::1]:57824 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 1XGWKS-0008KK-J1; Sun, 10 Aug 2014 09:50:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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:50:44 -0000
X-URL: http://tools.ietf.org/wg/6man/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/5#comment:1
Message-ID: <082.2f6b36f09458a02d96c3e91fa0512248@trac.tools.ietf.org>
References: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 5
In-Reply-To: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org>
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/mWERtmZI9OKOJo9TZlwsV-J0u0w
X-Mailman-Approved-At: Sun, 10 Aug 2014 09:52:02 -0700
Cc: roll@ietf.org, 6man@ietf.org
Subject: Re: [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:50:47 -0000
#5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption Comment (by mariainesrobles@gmail.com): ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08756.html From: Brian E Carpenter <brian.e.carpenter at gmail.com> Date: Wed, 30 Jul 2014 13:36:44 +1200 On 30/07/2014 12:02, Philip Levis wrote: ... > "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. I can't evaluate whether the energy saving is significant. However, I don't have any deep faith in the e2e-ness of the flow label. The reality (as RFC 6437 tries to recognise) is that it's a mutable field, and is therefore untrustworthy for e2e use. It has value for load balancing if all packets of a given flow have the same label, whether the label is set by the source or by a border device. For that reason, I think the usage proposed in this draft is OK. However, I do agree that at least a hand-waving estimate of the % energy saving would be useful. Brian Carpenter R ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08761.html From: Philip Levis <pal at cs.stanford.edu> Date: Thu, 31 Jul 2014 15:11:21 -0700 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote: > On 30/07/2014 12:02, Philip Levis wrote: > ... >> "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. > > I can't evaluate whether the energy saving is significant. > However, I don't have any deep faith in the e2e-ness of the > flow label. The reality (as RFC 6437 tries to recognise) > is that it's a mutable field, and is therefore untrustworthy > for e2e use. It has value for load balancing if all packets > of a given flow have the same label, whether the label is > set by the source or by a border device. For that reason, > I think the usage proposed in this draft is OK. > > However, I do agree that at least a hand-waving estimate of > the % energy saving would be useful. > > Brian Carpenter *shrug* My thoughts are pretty simple. I'm sure you know all this (as one of the authors!) but I'll revisit for everyone else's sake. 6437 states "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1." So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and should say so explicitly), or there should be an explicit update to 6437. In fact, the current draft is misleading and incorrect. It says "but the RFC also indicates a violation to the rule can be accepted for compelling reasons, and that security is a case justifying such a violation. This specification suggests that energy-saving is another compelling reason for a violation to the aforementioned rule." This is *not* what 6437 says. It says for compelling operational security reasons, not compelling reasons, of which one case is security. Having been researching, implementing, and deploying low-power protocols for over a decade, I've become exceedingly skeptical when someone proposes a protocol with energy as a motivation without quantifying it. For example, there are tons of protocols in the research literature which talk about using transmission power control to save energy (trading off range for power). But almost all of these papers ignore the fact that (unlike mobile/cellular systems, which the authors have been publishing in for years) RF is a tiny sliver of power in low-power networks. So reducing your transmission (RF) power by 99% only reduces your radio power by 50%. Generally a losing proposition. This is the same reason why power saving in WiFi involves synchronization on AP beacons and not adjusting transmit power. If someone doesn't quantify the potential benefit based on real hardware and protocols, then it could be based on mistaken assumptions. I mean, it doesn't take much here. Start with a working low-power RPL network. Send packets with sizes following a reasonable distribution based on an actual application. In one experiment send just those packets. In another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. Measure the energy cost. And, generally speaking, if you can't demonstrate the problem very easily, then perhaps it isn't a real problem at all. All that being said, I think using the flow label in this way is a good idea, and definitely valuable. But as it is now, doing so violates 6437, and so the assumptions implementers make when reading 6437. I think the bar for doing so should be high, higher than vague suggestions and hand waving which might not be correct. Phil ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08763.html From: Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> Date: Fri, 1 Aug 2014 10:50:15 +0200 Dear Phil, all, I do not completely agree :) Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. For me this is not different than changing the scope of the flow label inside the LLN to transport RPL information and resetting it at the LBR once data moves outside of the network considering that inside the LLN the flow label has no meaning. Looking into an article we wrote some time back, "A Realistic Energy Consumption Model for TSCH Networks". published in IEEE Sensors we know that the charge used by a mote (something similar to telosb) to send 127bytes is around 69uC and to receive them is 72uC (considering the optimal case where receiver has a guard time of 1ms and the network is synchronized). By using the flow label instead of the RPL extension header we save 5bytes which give us a gain 2,71uC per data packet per hop when sent and something similar when received (i.e ~5uC in total), this is a 8% saving (accounting TX and RX side) considering that motes are always using 127bytes packets. If we go to a more realistic case where motes send ~50bytes packets, the charge needed to send/receive them is something around 27.5uC and being able to save 5 bytes represents a 10% saving for the sender and 10% for the receiver (~20% saving if we look it overall per hop). If we use batteries that power the mote for 5 years, a 20% saving gives us ~1 more year which I think is pretty significant. regards, Xavi ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08764.html From: Carsten Bormann <cabo at tzi.org> Date: Fri, 1 Aug 2014 13:23:44 +0200 On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> wrote: > > Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. No. With IPHC, the flow label has always been there, it just was transmitted in a very compressed form. I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries. So much for O, R, F, and rank. Putting the VLAN (“instance ID”) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID. We normally try to hide IDs of this kind below IP. Now, I’m not saying any of this new architecture is wrong. I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization. (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.) The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”. Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it. So the evolution just eats it. Teachable moment. Grüße, Carsten ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08766.html From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 12:56:40 +0000 > No. With IPHC, the flow label has always been there, it just was transmitted > in a very compressed form. My take is that you are both providing angles on a same thing. It does not make sense for a LLN node to waste compute power and bandwidth to get a random through that is of use only in the core of the internet, should the packet ever get there. So the flow label is effectively zero - or something locally significant in specific standards, which is not design to serve the purpose of load balancing in the core. So in either case, we need the root to 'inflate' the zero flow label, or replace it by something that fits the core of the Internet. That behavior was not specified so far and it should be. This document is covering this particular gap. Cheers, Pascal ---------------- Source: http://www.ietf.org/mail-archive/web/roll/current/msg08767.html From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 13:25:06 +0000 > I think the visceral reaction that most of us have in using the flow label as a > mesh routing header is that this blurs the layer boundaries. So much for O, > R, F, and rank. Putting the VLAN ("instance ID") into the packet is a > significantly larger change, because it essentially extends the IP service > interface by a VLAN ID. We normally try to hide IDs of this kind below IP. > > Now, I'm not saying any of this new architecture is wrong. I just think what > we need to do is discuss this as the architectural change that it is, not as a > simple optimization. (The need for some kind of optimization of IP-in- IP > mesh routing for small-packet IoT applications is pretty obvious to me.) > > I agree, Carsten. An angle is that we allow for localized usage of the flow label as opposed to end-to-end. Another is that we allow for different semantics within a local domain, as long as the packet that leaves the local domain fits the requirements in RFC 6437. As you point out, it is worth noting that we include information about flow isolation and rules by which a flow will be routed, which is akin to Multi-Topology Routing though MTR is based on TOS bits. It would be good to design an architecture that encompasses such capabilities. We'll note that ISA100.11a is shipping with a flow label that contains an index to a state (so-called a contract) that is installed on the nodes on the way and by and large extends the notion of PHB on a per flow basis. Cheers, Pascal -- -------------------------------------------------+------------------------- 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 | Resolution: Keywords: | -------------------------------------------------+------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/5#comment:1> 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