Re: [Roll] using the flow label instead of hop by hop

Philip Levis <philip.levis@gmail.com> Sat, 20 October 2012 13:50 UTC

Return-Path: <philip.levis@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B962921F84E0 for <roll@ietfa.amsl.com>; Sat, 20 Oct 2012 06:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZAC2rSTMAfV for <roll@ietfa.amsl.com>; Sat, 20 Oct 2012 06:50:17 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD47021F8432 for <roll@ietf.org>; Sat, 20 Oct 2012 06:50:16 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id ro8so1077628pbb.31 for <roll@ietf.org>; Sat, 20 Oct 2012 06:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8TK3t7h/tu56kMi82R5avT3UNs9sowydIhfXBzBKpSs=; b=Tkapl4OK7/EDuBOhOMJ7l0msZ/KqIZFn1E9lYsTH8a6vAI8ax/o5GlAQWCVlhUBvK3 lh3vFL4mn5i+J5piyZbfAC0KAIrSdTwOZ1QNC4AEUdue+17QtjkMfR50L+gVO1iXjyu9 IJyIobXl49T3J0lwLQtSSHFJwFm10hepA9cFDaSKJ1B/Sjs8CU+2g48dAe/21zmOfs+4 R4sKngxhqHHIrkW5sn/Uz1gAK+BAzryp+dW10VQXYJnStDKecqKmE/hG/mj6ekMLpDxh eMY4G+qxTIK3Ri2A46xteC8JfVNRmpueQQd6cAF28FjEnHTv+EmWIXD0LZ1ndw8uHou+ S4XA==
Received: by 10.68.237.167 with SMTP id vd7mr5773617pbc.161.1350741016549; Sat, 20 Oct 2012 06:50:16 -0700 (PDT)
Received: from [192.168.0.106] ([76.14.66.110]) by mx.google.com with ESMTPS id oi2sm2866210pbb.62.2012.10.20.06.50.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Oct 2012 06:50:15 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Philip Levis <philip.levis@gmail.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD8221D8787@xmb-rcd-x01.cisco.com>
Date: Sat, 20 Oct 2012 06:50:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <33921BF9-9D15-49F8-AB15-55740DC984E1@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD8221D8787@xmb-rcd-x01.cisco.com>
To: Pascal Thubert <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1278)
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] using the flow label instead of hop by hop
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sat, 20 Oct 2012 13:50:18 -0000

On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote:

> Phil;
> 
> There is indeed lot of pressure for this in terms of header sizes and energy consumption in the *real world*.

I'm personally concerned about header sizes and energy consumption in The Matrix. Because I don't live in the real world. Oh, wait, sorry, I do. Can you walk me through the quantitative reasoning that a few bytes of header will increase energy consumption? It the belief that it will lead to sub-packet fragmentation in some non-amortized sense? Generally speaking, in low power wireless networks, energy consumption is dominated by idle listening and communication latency/interval support, not the length of packets. Of course there is a spectrum of low power approaches and their point on that spectrum. Are you thinking of one in particular?

Could implementers who are encountering this pressure comment? I'm a sucker for and easily swayed by quantitative data as well as first-hand rather than second-hand reports.

> And there is no hack in the proposed solution.
> Simply we believe more in practical engineering and ML discussions than we trust in crystal balls. 

*coughs politely* I believe in very practical engineering that considers long term consequences. Solving a problem a certain way now might cause significant problems in the future. I agree this is a tradeoff -- in my personal opinion, nothing more, the tradeoff on this one is 100% clear.

Phil

------

Philip Levis
President, Kumu Networks
Associate Professor, Stanford University
http://csl.stanford.edu/~pal