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

Xavier Vilajosana <> Fri, 01 August 2014 08:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3B9F1A030D; Fri, 1 Aug 2014 01:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rAfW_WCWya9J; Fri, 1 Aug 2014 01:50:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 087061A010D; Fri, 1 Aug 2014 01:50:15 -0700 (PDT)
Received: by with SMTP id hn18so1161385igb.3 for <multiple recipients>; Fri, 01 Aug 2014 01:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hsGlE5ethnUo51DLtSkziO+xogSTV0FnomfyTMbLajE=; b=jTcPiZYbUAqvecNGsWM/XrjkulibrsBz8W0Yit1stWEvEMrJzmt3v7rTrhVGZ4990f g9hyttpjmr9tH0F1oJ93AccnGhZFqm1OH49OovanVvrwWQcmPqkH/LYRVg7OraoMOT0b bWQK6HJUF46bRjfErrpe85Bn/LP7XLDiZIgUJYSR3ke+KQ+IdRD5JXVgbC1lL9QbMM3h 2EDsPhBfohw7OPSnrwYy8MNfSOhuU/pUkgFhGSESq+d9wcABhtEPQrcNYd/uE8Xd7w9c zh37vNEM8a/dWfwXvIMYtbTAlMOILr+/szurtzdvL+pu6tGfLadPlSADJFtckvC3Ulxu F4ew==
MIME-Version: 1.0
X-Received: by with SMTP id k15mr5287828icp.42.1406883015394; Fri, 01 Aug 2014 01:50:15 -0700 (PDT)
Received: by with HTTP; Fri, 1 Aug 2014 01:50:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 01 Aug 2014 10:50:15 +0200
X-Google-Sender-Auth: _k70OTDGsaT1OR1GClrs1hWOAWo
Message-ID: <>
From: Xavier Vilajosana <>
To: Philip Levis <>
Content-Type: multipart/alternative; boundary="20cf303dd3b05f8a8f04ff8d7a46"
X-Mailman-Approved-At: Fri, 01 Aug 2014 02:38:58 -0700
Cc: Brian Haberman <>, "" <>, Michael Richardson <>, roll <>, Ines Robles <>, Bob Hinden <>, Ole Troan <>, Brian E Carpenter <>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Aug 2014 08:50:18 -0000

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.


2014-08-01 0:11 GMT+02:00 Philip Levis <>:

> On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <
>> 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------