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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 01 August 2014 12:44 UTC

Return-Path: <pthubert@cisco.com>
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 243141A0B00; Fri, 1 Aug 2014 05:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kyycVQksyiF0; Fri, 1 Aug 2014 05:44:49 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9046C1A0B04; Fri, 1 Aug 2014 05:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6467; q=dns/txt; s=iport; t=1406897086; x=1408106686; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c/WKTYA/5UNVR/gnH9rZnEDWWLXiE++Vy3iLXfbKTpw=; b=PTFlutIxvO6jK7cT5hc8aq9wUsqp9+Ij+AqOeSaAjkNO5BBzV+tFHm2e 4bBHSPP6KUV75M1Yl95w//lfLb/VH7UV0C4KvDGTduaN0CTF87Cs9Wj8P AQ9VNPIDA+3RwfzAGnkhGMdVWcXLO0ZVocAdwktLon7AGk4SJyQd83O2N w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFADeL21OtJV2T/2dsb2JhbABPDA6Cf4EpBNNTAYEIFneEAwEBAQQdShIMBAIBCA4DBAEBAQodByERFAkIAgQBDQUIiCYDEcJrDYcPF40fgUYBGB0xBwaDKYEcBYpMjyKQOoYlgwdCbAGBRA
X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344417706"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2014 12:44:42 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s71CigDg001383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:44:42 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:44:42 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPq3MQL9UY5QNEnE6ScMk7SCjlQJu4D/iAgAAaYwCAAutIgIAAk91g
Date: Fri, 01 Aug 2014 12:44:41 +0000
Deferred-Delivery: Fri, 1 Aug 2014 12:44:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu>
In-Reply-To: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.197.62]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/4H5QZdZ-vKr4iJJkcCp04ktOtZc
X-Mailman-Approved-At: Fri, 01 Aug 2014 05:47:39 -0700
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, Bob Hinden <bob.hinden@gmail.com>, "Ole Troan (otroan)" <otroan@cisco.com>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: 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: Fri, 01 Aug 2014 12:44:52 -0000

Hello Phil:

The end-to-end principle will not break in pieces if we reuse the flow label field within the LLN. 

FYI, it will break nothing since there is no assumption in the Internet that the flow label will be carried unchanged. Consistently, there is no native way to secure the flow label to make sure it was not tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP transport mode). 

The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does.

About SDOs: To be very clear, ISA100.11a made a clear condition to acceptance of 6LoWPAN that we compress the UDP checksum - 2 bytes. And we made that happen.
As the standard is now considering what new work may be taken in, RPL will not be considered if we waste those 5 bytes, simple as that. Sorry that you missed the ROLL meeting, but Pat Kinney was very clear on that both as vice chair of 802.15,  and as chair of ISA100.11a where he "fought over every byte". " Both hats say that this is what we need this".

We'll also note that each additional octet in a frame is an increased chance of loss and retry. This is an argument that I hear frequently at IEEE and the people there as well as at ISA100 are very sensitive to frame size in general.

The distribution of the frame size and the cost of security depend on the application and the app layer. With high levels of security, if the distribution includes NLPDU around 80-90 octets then the extra bytes will cause fragmentation, which will add all sorts of new problems to the picture.

The benefits are quite clear, both on actual numbers (thanks Xavi!) and on the political arena where such a waste of bytes is just not defendable.

Please reconsider where you are placing your efforts and what you are trying to achieve...

Pascal


> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> Sent: vendredi 1 août 2014 00:11
> To: Brian E Carpenter
> Cc: Ines Robles; Brian Haberman; ipv6@ietf.org; Michael Richardson; roll;
> Bob Hinden; Ole Troan (otroan); Pascal Thubert (pthubert); Adrian Farrel
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> 
> On Jul 29, 2014, at 6:36 PM, Brian E Carpenter
> <brian.e.carpenter@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