[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" <[e-mail]>]

#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:  [e-mail]            |      Owner:
     Type:  defect                               |  [e-mail]
 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/>