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

Philip Levis <pal@cs.stanford.edu> Mon, 04 August 2014 18:24 UTC

Return-Path: <pal@cs.stanford.edu>
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 4216E1A005C; Mon, 4 Aug 2014 11:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 bYjxXJv1vA51; Mon, 4 Aug 2014 11:24:48 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB211A00E5; Mon, 4 Aug 2014 11:24:35 -0700 (PDT)
Received: from 108-192-17-194.lightspeed.sntcca.sbcglobal.net ([108.192.17.194]:49959 helo=phoenix.att.net) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XEMvy-0001V9-Lr; Mon, 04 Aug 2014 11:24:35 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <23675.1407160947@sandelman.ca>
Date: Mon, 04 Aug 2014 11:24:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FA35615-C9A0-4591-B60B-874B95E87D1E@cs.stanford.edu>
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> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com> <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu> <23675.1407160947@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 2c21b60125577a2cbf52524016395bed
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ixcKipQ7-vI_8vJMbbj1Y4OYQ80
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
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: Mon, 04 Aug 2014 18:24:50 -0000

On Aug 4, 2014, at 7:02 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

> 
> Philip Levis <pal@cs.stanford.edu> wrote:
>> 5% or 10% isn't huge, but it is significant and valuable. I've just
>> been a bit confused as to why this proposal has been trotted around for
>> 4 years and yet no-one had yet even done this simple calculation, so WG
>> members could make an informed engineering decision. IMO, a 5-10%
> 
> my opinion:
> 
> 1) the exact calculation was hard to really do until 6tisch made it clearer
>   what the duty cycle was going to be.
> 
> 2) it took awhile to come back to figuring out how to deal with the flow
>   label issue.
> 
> 3) it is now clear exactly how close many of our packets are to the 127 byte
>   limit, and how much the HbH header hurts if it is the reason we go into
>   two fraglets.
> 
> 4) we had other things to worry about!

Michael,

1) doesn't depend on 6tisch, it's based on 15.4e timing, and could have been calculated for any other low power link layer. Years ago.

2) The proposal isn't substantively different -- in terms of bytes sent/saved -- from the first version of the proposal suggested in 2010.

3) The analysis so far hasn't even touched this issue.

4) The entire introduction/motivation for the proposal is saving energy! But no-one thought it important enough to actually estimate how much energy it would save (in a best case, typical case) before a last call?

Here's my worry -- the tradeoffs of low-power networks are very different than the kinds of networks the IETF typically deals with. It'll lead to protocol decisions a bit different than always-on networks. But that doesn't mean it should be used as a blanket justification or motivation. Otherwise it's just smoke and mirrors (energy is critical! battery is critical! we therefore need less CPU-intensive compression schemes! here's a new one. we need less CPU-intensive cryptographic schemes! here's a new one.). If energy is so important, and this would be such a big savings, then why the recalcitrance to estimate it?  It doesn't help my confidence in the engineering when some of the back-of-the-envelope analyses (Xavier's) have basic arithmetic errors that seem incognizant of how to measure energy. 

Phil