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

From: Ines Robles <[email-masked]>
Date: Wed, 30 Jul 2014 00:21:28 +0300

Dear 6man and roll WGs,

We announce a joint Working Group Last Call for
draft-thubert-6man-flow-label-for-rpl-03
<http://tools.ietf.org/html/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,

6man and roll chairs.

---

From: Philip Levis <[email-masked]>
Date: Tue, 29 Jul 2014 17:02:17 -0700

On Jul 29, 2014, at 2:21 PM, Ines Robles <[email-masked]> 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.
> 

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

---

From: Brian E Carpenter <[email-masked]>
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

---

From: Philip Levis <[email-masked]>
Date: Thu, 31 Jul 2014 15:11:21 -0700

> the % energy saving would be useful.

*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