[Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation

"6man issue tracker" <trac+6man@trac.tools.ietf.org> Sun, 10 August 2014 16:57 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 8F5841A0573; Sun, 10 Aug 2014 09:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1M2n7VcU1bTN; Sun, 10 Aug 2014 09:57:11 -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 2787F1A0005; Sun, 10 Aug 2014 09:57:11 -0700 (PDT)
Received: from localhost ([::1]:58025 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 1XGWQf-0001Jq-MX; Sun, 10 Aug 2014 09:57:09 -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:57:09 -0000
X-URL: http://tools.ietf.org/wg/6man/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6
Message-ID: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org>
X-Trac-Ticket-ID: 6
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/VLH-s4czKgRSxYNOCXaVFIjVOFU
X-Mailman-Approved-At: Sun, 10 Aug 2014 10:32:47 -0700
Cc: roll@ietf.org, 6man@ietf.org
Subject: [Roll] [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation
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:57:12 -0000

#6: draft-thubert-6man-flow-label-for-rpl-03  Updates: 6437 (if approved)  -
add section with explanation

 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

-- 
-------------------------------------------------+-------------------------
 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/6>
6man <http://tools.ietf.org/wg/6man/>