From roll-bounces@ietf.org Mon Nov 3 01:19:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF31D3A684A; Mon, 3 Nov 2008 01:19:19 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726C03A684A for ; Mon, 3 Nov 2008 01:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqHmR-nT1+vZ for ; Mon, 3 Nov 2008 01:19:17 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 01C2C3A6843 for ; Mon, 3 Nov 2008 01:19:16 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so1295124tib.25 for ; Mon, 03 Nov 2008 01:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=moSCE3RXrxylj/V3pO42BRB6htTa7BxUSrvKX5hrm10=; b=CLYoHtrwMrXhz+8gyt5rtHf6z87G7qPM+p2x6ANiOLG6FuoU7uaf9F2IFJASrOQ6Cl B01VOdld45ueFyrjoa2whxNoSvCl2KlI0GCF4bWN/P6QMP5xHMnJ03YpwQ282TUUuVr0 mU9k+BOIIEvrwl4W/mBJPenCTxOGE2Ygq2AFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=IF4+YdMfomibkSVUivyH19ALs5BRVpX0cjHVSAZXV3O+Iwx4movIZ0IAid2J9kgqXx HZMT7C/DcUviomUdWl/sXIzQt8DUiq+dUeyE8Ht09eSgoImKXUoI5ouhJ3y8OZmzPvjl NUHF0TykvNZuTFdQt8N0f347IpIueF1H7+FA4= Received: by 10.110.93.12 with SMTP id q12mr11104998tib.41.1225703954541; Mon, 03 Nov 2008 01:19:14 -0800 (PST) Received: by 10.110.41.3 with HTTP; Mon, 3 Nov 2008 01:19:14 -0800 (PST) Message-ID: Date: Mon, 3 Nov 2008 18:19:14 +0900 From: "MiJeom Kim" To: "Philip Levis" In-Reply-To: <9302B802-A999-4D48-B667-BE092554D4B7@cs.stanford.edu> MIME-Version: 1.0 References: <9302B802-A999-4D48-B667-BE092554D4B7@cs.stanford.edu> Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0082327608==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0082327608== Content-Type: multipart/alternative; boundary="----=_Part_74395_44327.1225703954537" ------=_Part_74395_44327.1225703954537 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Phil, You are absolutely right. I missed link asymmetry. However, in link state protocols, nodes keep the list of neighbors. Even in distance vector protocols, I think there is a high chance for nodes to be aware of their neighbors as time goes. As you mentioned, for constrained nodes, it might be overhead to keep the neighbor list. But, I don't think it is very resource consuming to find out the neighbors unless considering very dynamic networks. My main concern is whether we need the node degree as a LLN routing metric and if we do, how we manipulate it. As the document says, it is questionable whether high node degrees are preferable or not. The decision requires too many factors need to be considered. Consequently, it's challenging to make use of node degree as a metric. Thanks. Mijeom. On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis wrote: > > On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: > > >> 4.6: Is the intention that a node calculates its degree? This is very >> difficult (some might say impossible under any realistic network scenario). >> First, it requires O(n^2) communication. The observation that routing >> protocols might want to change decisions based on density makes sense, but >> by stating it is a metric that implies nodes calculate it. >> ===> >> I think a node can figure out its degree by overhearing. So as time goes, >> it can get the number of neighbors more precisely. >> > > That would be true if degree were defined as the number of neighbors a node > can hear. However, it's defined as > > Node degree is the number of neighbors that can receive a message > from the node directly. > > Unless you assume asymmetric links do not exist, this requires each node to > report the set of nodes from which it hears messages, so those nodes can > calculate their degree. It also requires a node to maintain state linear in > the number of its neighbors, which is problematic. > > Phil > ------=_Part_74395_44327.1225703954537 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj48Zm9udCBmYWNlPSJhcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+SGksIFBoaWwsPC9m b250PjwvZGl2Pgo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj48 L2ZvbnQ+Jm5ic3A7PC9kaXY+CjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWYiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3UgYXJlIGFic29sdXRlbHkgcmlnaHQuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICYjMzk7VGltZXMgTmV3IFJv bWFuJiMzOTs7IG1zby1hc2NpaS1mb250LWZhbWlseTogudnFwSI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj5JIG1pc3NlZCBsaW5rIGFzeW1tZXRyeS48L3NwYW4+PC9mb250PjwvZGl2 PgoKPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi Pjxmb250IGZhY2U9ImFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj48c3BhbiBsYW5nPSJFTi1V UyI+SG93ZXZlciwgaW4gbGluayBzdGF0ZSBwcm90b2NvbHMsIG5vZGVzIGtlZXAgdGhlIGxpc3Qg b2YgbmVpZ2hib3JzLiBFdmVuIGluIGRpc3RhbmNlIHZlY3RvciBwcm90b2NvbHMsIEkgdGhpbmsg dGhlcmUgaXMgYSBoaWdoIGNoYW5jZSBmb3Igbm9kZXMgdG8gYmUgYXdhcmUgb2YgdGhlaXIgbmVp Z2hib3JzIGFzIHRpbWUgZ29lcy4gQXMgeW91IG1lbnRpb25lZCwgZm9yIGNvbnN0cmFpbmVkIG5v ZGVzLCBpdCBtaWdodCBiZSBvdmVyaGVhZCB0byBrZWVwIHRoZSBuZWlnaGJvciBsaXN0LiBCdXQs IEkgZG9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1GQU1JTFk6ICYjMzk7 VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1hc2NpaS1mb250LWZhbWlseTogudnFwSI+Jzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+dCB0aGluayBpdCBpcyB2ZXJ5IHJlc291cmNlIGNvbnN1bWlu ZyB0byBmaW5kIG91dCB0aGUgbmVpZ2hib3JzIHVubGVzcyBjb25zaWRlcmluZyB2ZXJ5IGR5bmFt aWMgbmV0d29ya3MuIDwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJh cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Zm9udCBmYWNlPSJh cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PHNwYW4gbGFuZz0iRU4tVVMiPk15Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogudnFwTsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1oYW5zaS1mb250LWZhbWls eTogJiMzOTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICYjMzk7 VGltZXMgTmV3IFJvbWFuJiMzOTs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0OyBtc28tYW5zaS1s YW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj5tYWluIGNvbmNlcm4gaXMgd2hldGhlciB3ZSBuZWVkIHRoZSBub2RlIGRlZ3Jl ZSBhcyBhIExMTiByb3V0aW5nIG1ldHJpYyBhbmQgaWYgd2UgZG8sIGhvdyB3ZSBtYW5pcHVsYXRl IGl0LiBBcyB0aGUgZG9jdW1lbnQgc2F5cywgaXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRoZXIgaGln aCBub2RlIGRlZ3JlZXMgYXJlIHByZWZlcmFibGUgb3Igbm90LiBUaGUgZGVjaXNpb24gcmVxdWly ZXMgdG9vIG1hbnkgZmFjdG9ycyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQuIENvbnNlcXVlbnRseSwg aXQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiAmIzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tYXNjaWktZm9udC1mYW1pbHk6 ILnZxcE7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0OyBtc28tZm9udC1rZXJuaW5nOiAxLjBw dDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1z by1iaWRpLWxhbmd1YWdlOiBBUi1TQTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ILnZxcEiPic8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiC52cXBOyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWhhbnNpLWZvbnQtZmFt aWx5OiAmIzM5O1RpbWVzIE5ldyBSb21hbiYjMzk7OyBtc28tYmlkaS1mb250LWZhbWlseTogJiMz OTtUaW1lcyBOZXcgUm9tYW4mIzM5OzsgbXNvLWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNp LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1sYW5n dWFnZTogQVItU0EiPnMgY2hhbGxlbmdpbmcgdG8gbWFrZSB1c2Ugb2Ygbm9kZSBkZWdyZWUgYXMg YSBtZXRyaWMuPC9zcGFuPjwvZm9udD48L3A+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PGZvbnQgZmFjZT0iYXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWYiPjwvZm9udD4mbmJzcDs8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0Ij48Zm9udCBmYWNlPSJhcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZiI+VGhhbmtzLjwvZm9udD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0Ij48Zm9udCBmYWNlPSJhcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+TWlq ZW9tLjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0iYXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxi cj48L2ZvbnQ+PC9wPgo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU2F0LCBOb3YgMSwgMjAw OCBhdCAxOjEzIEFNLCBQaGlsaXAgTGV2aXMgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt YWlsdG86cGFsQGNzLnN0YW5mb3JkLmVkdSI+cGFsQGNzLnN0YW5mb3JkLmVkdTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBB RERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDog I2NjYyAxcHggc29saWQiPgo8ZGl2IGNsYXNzPSJJaDJFM2QiPjxicj5PbiBPY3QgMzEsIDIwMDgs IGF0IDE6MjAgQU0sIE1pSmVvbSBLaW0gd3JvdGU6PGJyPjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAw cHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+PGJyPjQuNjogSXMgdGhlIGlu dGVudGlvbiB0aGF0IGEgbm9kZSBjYWxjdWxhdGVzIGl0cyBkZWdyZWU/IFRoaXMgaXMgdmVyeSBk aWZmaWN1bHQgKHNvbWUgbWlnaHQgc2F5IGltcG9zc2libGUgdW5kZXIgYW55IHJlYWxpc3RpYyBu ZXR3b3JrIHNjZW5hcmlvKS4gRmlyc3QsIGl0IHJlcXVpcmVzIE8obl4yKSBjb21tdW5pY2F0aW9u LiBUaGUgb2JzZXJ2YXRpb24gdGhhdCByb3V0aW5nIHByb3RvY29scyBtaWdodCB3YW50IHRvIGNo YW5nZSBkZWNpc2lvbnMgYmFzZWQgb24gZGVuc2l0eSBtYWtlcyBzZW5zZSwgYnV0IGJ5IHN0YXRp bmcgaXQgaXMgYSBtZXRyaWMgdGhhdCBpbXBsaWVzIG5vZGVzIGNhbGN1bGF0ZSBpdC48YnI+Cj09 PSZndDs8YnI+SSB0aGluayBhIG5vZGUgY2FuIGZpZ3VyZSBvdXQgaXRzIGRlZ3JlZSBieSBvdmVy aGVhcmluZy4gU28gYXMgdGltZSBnb2VzLCBpdCBjYW4gZ2V0IHRoZSBudW1iZXIgb2YgbmVpZ2hi b3JzIG1vcmUgcHJlY2lzZWx5Ljxicj48L2Jsb2NrcXVvdGU+PGJyPjwvZGl2PlRoYXQgd291bGQg YmUgdHJ1ZSBpZiBkZWdyZWUgd2VyZSBkZWZpbmVkIGFzIHRoZSBudW1iZXIgb2YgbmVpZ2hib3Jz IGEgbm9kZSBjYW4gaGVhci4gSG93ZXZlciwgaXQmIzM5O3MgZGVmaW5lZCBhczxicj4KPGJyPiZu YnNwOyBOb2RlIGRlZ3JlZSBpcyB0aGUgbnVtYmVyIG9mIG5laWdoYm9ycyB0aGF0IGNhbiByZWNl aXZlIGEgbWVzc2FnZTxicj4mbmJzcDsgZnJvbSB0aGUgbm9kZSBkaXJlY3RseS48YnI+PGJyPlVu bGVzcyB5b3UgYXNzdW1lIGFzeW1tZXRyaWMgbGlua3MgZG8gbm90IGV4aXN0LCB0aGlzIHJlcXVp cmVzIGVhY2ggbm9kZSB0byByZXBvcnQgdGhlIHNldCBvZiBub2RlcyBmcm9tIHdoaWNoIGl0IGhl YXJzIG1lc3NhZ2VzLCBzbyB0aG9zZSBub2RlcyBjYW4gY2FsY3VsYXRlIHRoZWlyIGRlZ3JlZS4g SXQgYWxzbyByZXF1aXJlcyBhIG5vZGUgdG8gbWFpbnRhaW4gc3RhdGUgbGluZWFyIGluIHRoZSBu dW1iZXIgb2YgaXRzIG5laWdoYm9ycywgd2hpY2ggaXMgcHJvYmxlbWF0aWMuPGJyPgo8YnI+UGhp bDxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= ------=_Part_74395_44327.1225703954537-- --===============0082327608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0082327608==-- From roll-bounces@ietf.org Mon Nov 3 10:02:32 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CB73A6BF6; Mon, 3 Nov 2008 10:02:32 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2FA3A6BF0 for ; Mon, 3 Nov 2008 10:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m0QqTcR+lZL for ; Mon, 3 Nov 2008 10:02:30 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id DFDD93A686D for ; Mon, 3 Nov 2008 10:02:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2DFF3AF8AE; Mon, 3 Nov 2008 10:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcBYblwEo1Aw; Mon, 3 Nov 2008 10:02:25 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 5AFFFAF8A3; Mon, 3 Nov 2008 10:02:25 -0800 (PST) Message-Id: <628C538F-D023-482F-8C94-047D87A49DDC@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 10:02:24 -0800 References: X-Mailer: Apple Mail (2.929.2) Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This draft is an excellent starting point and has already generated a = lot of good discussion. Here are some of my own comments: - Section 4.3 and 4.4: I understand that these are important metrics = with more traditional (higher power) link technologies, but I think = the description does not sufficiently characterize the challenges in = LLNs. In general, most of the high-order bits in these metrics will be = due to communication delays at the link layer (scheduled communication = as well as conservative backoffs can cause communication delays on the = order of seconds and even 10s of seconds). This can easily dwarf all = other delays caused by processing times. For the networks I'm used to = dealing with, I'd argue that communication latency is much more = significant than node workload. - Section 4.5: I'm not convinced that the Data Aggregation attribute = is best to have within the network layer. Data aggregation is = application specific. The great thing about route-over is that it = exposes all of the physical connectivity above IP, and doing so = supports the construction of higher-layer structures (i.e. overlays) = that can support things like in-network processing. I personally feel = that data aggregation is best left for higher layers. - Section 4.6: I share the same concern with Phil. While even DV = protocols maintain neighbors, the strict resource constraints of LLNs = often restrict nodes to maintaining state about a *subset* of their = neighbors. I do believe that maintaining a node's degree in terms of = bi-directional links will not fit within the resource constraints of = typical LLNs in the general case. However, degree is a useful metric = to have, if we can both define and evaluate it properly. - Section 4.7: Agreeing with what was mentioned earlier on the list, = the distinction between Dynamicity (4.7) and Link Reliability (5.2) = is not obvious to me. In some sense, we have only marginal control = over network topology and node behaviors - they are often driven by = surrounding environmental factors. - Section 5.1: I think the metric we really want here is throughput. = Bandwidth is only one of many factor that affects the link's throughput. - Section 5.2: Just a personal opinion here, but I strongly believe = that bi-directional link success rates (PRR) will be much more useful = than directional success rates. Due to the lossy nature of LLNs, I = expect most, if not all, LLNs to utilize link-layer acknowledgments. = Furthermore, enforcing metrics to be bi-directional have significant = simplification advantages with respect to routing. - Section 5.3: I suggest renaming this attribute to Path Delay to = better describe the latency of delivering a message across the entire = path. Propagation Delay has already caused some confusion on this list = and, as traditionally defined, is fairly insignificant compared to the = other causes of delivery delays. - Section 5.4: As mentioned with 5.2, bi-directional links are not = just important for routing, but to enable the use of link mechanisms = such as link-layer acknowledgements. Are there others that feel = strongly against preferring routes that support relatively good bi- = directional communication? - Section 6: I think it's best to leave the first paragraph in and = strike the remaining two. It's useful to give the warning, but we = don't have to explain how to address it in this draft. -- Jonathan Hui On Oct 20, 2008, at 10:14 PM, JP Vasseur wrote: > Dear WG, > > As you know, routing metrics for LLN are part of our WG charter. = > draft-mjkim-roll-routing-metrics-01 is a first draft attempting to = > list a set of link and node metrics candidates. We intentionally = > left a wide set of metrics of various nature: link/node, static/ = > dynamic, ... > > We of course have to be quite careful here: defining metrics is one = > thing, determining what to do and how to make a careful use of it is = > the hard part. There is a number of notorious examples where metrics = > have been defined but have never been used simply for a number of = > reasons: > =95 Computing an aggregated metric as a polynomial function of a set = > of metrics is too difficult to operate, > =95 Use of a set of attributes as hierarchical constraints implies = > heavy policy configuration, > =95 Use of dynamic metrics was the source of routing oscillations = > (e.g. ARPANET) > =95 .... > > So we would need your feed-back, bearing in mind that we may want to = > only keep the metrics that are critical to LLNs. > > Waiting for your comments ... > > Thanks. > > JP and Kim. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 3 11:02:42 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C154228C0FA; Mon, 3 Nov 2008 11:02:42 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF80428C0FA for ; Mon, 3 Nov 2008 11:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.526 X-Spam-Level: X-Spam-Status: No, score=-5.526 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ02LvnUaBDI for ; Mon, 3 Nov 2008 11:02:41 -0800 (PST) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 9D1263A6A9B for ; Mon, 3 Nov 2008 11:02:40 -0800 (PST) Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 03 Nov 2008 19:02:17 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA3J2GKO022126 for ; Tue, 4 Nov 2008 06:02:16 +1100 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA3J2Fjm005860 for ; Mon, 3 Nov 2008 19:02:15 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 14:02:15 -0500 Received: from 10.55.201.131 ([10.55.201.131]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 Nov 2008 19:02:15 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 03 Nov 2008 20:02:14 +0100 From: JP Vasseur To: Message-ID: Thread-Topic: Draft Agenda - ROLL WG Meeting Thread-Index: Ack95q66Oh+5YRQNuUy1fS1Lf19SIA== Mime-version: 1.0 X-OriginalArrivalTime: 03 Nov 2008 19:02:15.0519 (UTC) FILETIME=[AFA246F0:01C93DE6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1169; t=1225738937; x=1226602937; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20Agenda=20-=20ROLL=20WG=20Meeting |Sender:=20; bh=nTIh52tT+IiRaphMO/r3rQ1sw/+FQXtQlMqQBlzYx0Q=; b=EpIM+YliQsrKgVw0A5hs2zF2UofDUpuWaUX9riph4QU7DgfNOT5kGJiM7X VecUwKjAobyPQLXy0oRJrgBGVyiA0XF8i6jnGLKGTO5R0Lp6GRF4Y5uvb9FX 9zzilHKWOIx6GByPhgYG7KXbhgx2QmWQVcMlphIU8ivydObuYC35M=; Authentication-Results: syd-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Subject: [Roll] Draft Agenda - ROLL WG Meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1257112229==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1257112229== Content-type: multipart/alternative; boundary="B_3308587334_23318257" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308587334_23318257 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, Please find the draft agenda for the ROLL WG Meeting IETF-73: http://www.ietf.org/proceedings/08nov/agenda/roll.txt If you have a slot thanks to send your slides by Nov 12. Let us know if you have any comment. Thanks. JP. --B_3308587334_23318257 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Draft Agenda - ROLL WG Meeting Dear all,

Please find the draft agenda for the ROLL WG Meeting IETF-73: http://www.ietf.org/proce= edings/08nov/agenda/roll.txt

If you have a slot thanks to send your slides by Nov 12.

Let us know if you have any comment.

Thanks.

JP. --B_3308587334_23318257-- --===============1257112229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1257112229==-- From roll-bounces@ietf.org Mon Nov 3 12:44:28 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A873A6C40; Mon, 3 Nov 2008 12:44:28 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24243A6C5C for ; Mon, 3 Nov 2008 12:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zas8KYr+8U5 for ; Mon, 3 Nov 2008 12:44:25 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 309EF3A6C40 for ; Mon, 3 Nov 2008 12:44:21 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mA3Kgats004880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2008 12:42:37 -0800 (PST) Message-ID: <490F6237.8020206@eecs.berkeley.edu> Date: Mon, 03 Nov 2008 12:42:31 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176105112==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1176105112== Content-Type: multipart/alternative; boundary="------------030205060800020300000200" This is a multi-part message in MIME format. --------------030205060800020300000200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit JP Vasseur wrote: > Hi Phil, > > > On 10/31/08 5:20 PM, "Philip Levis" wrote: > > >> On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote: >> >> >>> Agree. >>> >>> A good time to ask the question to the WG. >>> >>> Do you think that we need to specify node latency as a metric ? Note >>> that this mean: queueuing delays (per link) and processing time (per >>> node). >>> >>> ps: I¹m personally very skeptical about using such varying >>> metrics ... W/o high risk of routing oscillations, or we need very >>> carefully designed threshold-based mechanisms certainly no dynamic >>> metrics reflecting ³real time² values. >>> >> Node latency -- the time that passes between packet reception and >> packet transmission -- can be important but not for either queueing >> delay or processing time. >> > > That depends ... On the type of nodes, traffic type, ... Etc. > > Rather, node latency can be important if > >> there is some kind of underlying scheduling. Or would you consider >> this queueing delay? >> > > By "underlying scheduling" are you referring to the OS scheduler or the L2 > scheduling ? > I don't think that the OS scheduler or any other computation-related delay is likely to cause much trouble. Most/all existing motes can turn a packet around in milliseconds. The L2 access is a much bigger challenge. Unless you have the luxury of a powered routing infrastructure, one way or the other you'll be duty cycling your receivers. This will introduce delays of typically hundreds of milliseconds (tens of ms up to seconds). > Note that it can differ greatly depending on > >> which node is the next hop. >> > > But before we start to look at all components, I think that *the* question > is whether we want the routing protocol to take into account such highly > variable node and link metrics ? > I would love to see a routing protocol that can satisfy our requirements without taking into account the variable node and link metrics. If we weren't trying to be efficient, then there would be no problem. But the first L implies that we must be efficient, and the second L makes it very challenging to do that without paying close attention to what's going on at the link level. ksjp > Thanks. > > JP. > > >> Phil >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------030205060800020300000200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

JP Vasseur wrote: 
Hi Phil,


On 10/31/08 5:20 PM, "Philip Levis" <pal@cs.stanford.edu> wrote:

  
On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote:

    
Agree.

A good time to ask the question to the WG.

Do you think that we need to specify node latency as a metric ? Note
that this mean: queueuing delays (per link) and processing time (per
node).

ps: I¹m personally very skeptical about using such varying
metrics ... W/o high risk of routing oscillations, or we need very
carefully designed threshold-based mechanisms certainly no dynamic
metrics reflecting ³real time² values.
      
Node latency -- the time that passes between packet reception and
packet transmission -- can be important but not for either queueing
delay or processing time.
    

That depends ... On the type of nodes, traffic type, ... Etc.

Rather, node latency can be important if
  
there is some kind of underlying scheduling. Or would you consider
this queueing delay?
    

By "underlying scheduling" are you referring to the OS scheduler or the L2
scheduling ?
I don't think that the OS scheduler or any other computation-related delay is likely to cause much trouble.
Most/all existing motes can turn a packet around in milliseconds.
The L2 access is a much bigger challenge.  Unless you have the luxury of a powered routing infrastructure, one way or the other you'll be duty cycling your receivers.  This will introduce delays of typically hundreds of milliseconds (tens of ms up to seconds).
Note that it can differ greatly depending on
  
which node is the next hop.
    

But before we start to look at all components, I think that *the* question
is whether we want the routing protocol to take into account such highly
variable node and link metrics ?
I would love to see a routing protocol that can satisfy our requirements without taking into account the variable node and link metrics.  If we weren't trying to be efficient, then there would be no problem.  But the first L implies that we must be efficient, and the second L makes it very challenging to do that without paying close attention to what's going on at the link level.

ksjp
Thanks.

JP. 

  
Phil
    

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------030205060800020300000200-- --===============1176105112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1176105112==-- From roll-bounces@ietf.org Mon Nov 3 21:24:28 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F883A686E; Mon, 3 Nov 2008 21:24:28 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249DF3A677D for ; Mon, 3 Nov 2008 21:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1J35w2S6R7U for ; Mon, 3 Nov 2008 21:24:26 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 344C83A686E for ; Mon, 3 Nov 2008 21:24:26 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mA45OLok012293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2008 21:24:22 -0800 (PST) Message-ID: <490FDD77.7000205@eecs.berkeley.edu> Date: Mon, 03 Nov 2008 21:28:23 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org JP - I'd like to understand more about your flags. If I have a network in which I expect that all motes last for 7 years, where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 years)? At 5% (ideally 3 months)? In the first case, for roughly half of my network lifetime, all of my network will have set the "I'm low on energy" flag, and I will have no useful information with which to make routing decisions. In the second case, I have almost no useful information until it's too late - one year into operation and several of the busiest motes are almost dead, while a mote with a much bigger battery still has almost all of it's charge. So in this case the information shows up too late to be useful. I'm sure that's not the way you see it. What am I missing? ksjp JP Vasseur wrote: > Hi Miguel, > > > On 10/31/08 12:24 PM, "Miguel Sanchez" wrote: > > >> Hi JP, >> >> >> >> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur wrote: >> >>> Hi Kris, >>> >>> >>> On 10/30/08 5:33 PM, "Kris Pister" wrote: >>> >>> I agree with Miguel that we need a standard way of energy reporting, and I >>> agree with JP that it's hard to do. >>> Part of the challenge is that energy sources and storage vary so much. We >>> have: >>> * line power - great if you can get it! >>> * battery storage >>> - this is time varying. The available energy in a battery is a strong >>> function of the temperature and the usage profile. So a battery powered >>> mote may correctly calculate five years of lifetime in summer, and then that >>> winter under the exact same load conditions it may correctly calculate a >>> lifetime of ten years. The same mote with the same battery may have better >>> performance in summer at higher loads. >>> >>> JP> and usage profile may also change. >>> >>> * capacitive storage >>> * energy scavenging >>> - this is time varying, and tough to bound (usefully >>> >>> JP> this is why I'm questioning the usefulness of knowing the remaining >>> energy expressed in Joules or other metrics. Knowing this value will not >>> tell you anything as to whether you should or should not use that node when >>> computing the path. Another metric may be the remaining estimated lifetime >>> >> I disagree. >> >> At least if remaining energy is infinitum (mains powered) tells you something. >> >> OTOH, if limited, depending on other properties of the nodes (like >> where it gets its energy from) it is also useful for making routing >> decisions too. >> > > OK let's try to step back. I'm proposing a flag-based mechanism to avoid the > use of a node should this node run out of energy. The decision to set the > flag is made by the node (no specified) according to many parameters > (estimated like time, ... Etc). Some nodes having more power may make use of > complex models. > > If you advertise your remaining power in Joules, how would you expect the > nodes to change their routing decisions since they have no idea of whether > you are running low in energy (it highly depends on what the node does, the > external conditions, ... Etc) ? > > Thanks. > > JP. > > >>> but still, is the node capable (without consuming too much energy) of >>> gathering historical data etc ... to provide an accurate value hoping that >>> other criterion such as usage profile or temperature as you pointed out will >>> not change ? >>> >>> All of this makes energy/power/lifetime reporting painful, yet I can not >>> picture a successful routing protocol that doesn't somehow take these >>> factors into account. >>> >>> >> Kind regards, >> >> Miguel >> > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 3 23:46:35 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9603A684A; Mon, 3 Nov 2008 23:46:35 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887953A68A0 for ; Mon, 3 Nov 2008 23:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csihs6vI-kIN for ; Mon, 3 Nov 2008 23:46:32 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 701A63A67A1 for ; Mon, 3 Nov 2008 23:46:32 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1933862wag.5 for ; Mon, 03 Nov 2008 23:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=reP5boct3EahUiDmaaWfbMv3hr5Cb/LxejVbxxgMY3s=; b=HPxomIB0SaWAPxUiBWo+dRbuNl25bUey0sYvD+pztuj727XX2pDNZU59pr/ZjWt40N SNEhq2pF9RFB1w93edM8Jv0ZxcR6/KWVqaiFagnncUiHpN2jh5mv056C1PtWgftyDL9E cJbFbuhLFhNfr4c1V2GpQdFzoU2jqz+GtowqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=pOXkBaSCLz/1roXcUGu+2WbJGNvy+1gSyVyrhxrLY5O5g9UgsfWz6xSNqVeLo3QL7K b6Cz4zBBERKDVssradV/6GRHkHGYXdTqHuWe9RpVztj+XuMrANj8IaUtjwoJxG4Wd0Hk lup/iX8+l5HWt0zy6DfpIqEvVPI53u8ymaWvw= Received: by 10.114.57.15 with SMTP id f15mr721107waa.116.1225784789508; Mon, 03 Nov 2008 23:46:29 -0800 (PST) Received: by 10.114.158.12 with HTTP; Mon, 3 Nov 2008 23:46:29 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 16:46:29 +0900 From: "MiJeom Kim" To: "Jonathan Hui" In-Reply-To: <628C538F-D023-482F-8C94-047D87A49DDC@archrock.com> MIME-Version: 1.0 Content-Disposition: inline References: <628C538F-D023-482F-8C94-047D87A49DDC@archrock.com> Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, Jonathan, really appriciate your valuable comments. Please see below. On Tue, Nov 4, 2008 at 3:02 AM, Jonathan Hui wrote: > > - Section 4.3 and 4.4: I understand that these are important metrics with more traditional (higher power) link technologies, but I think the description does not sufficiently characterize the challenges in LLNs. In general, most of the high-order bits in these metrics will be due to communication delays at the link layer (scheduled communication as well as conservative backoffs can cause communication delays on the order of seconds and even 10s of seconds). This can easily dwarf all other delays caused by processing times. For the networks I'm used to dealing with, I'd argue that communication latency is much more significant than node workload. > > ==> I totally agree on what you said here. However, L2 delay depends on MAC protocols and it's very fluctuating by time. If there is high contention for a given channel, it takes more time to send a packet with contention based protocols. In contention-free protocols, L2 delay is more predictable and consistent. Due to the all dependency, I do not think it is possible to make L2 delay as a routing metric. > > - Section 4.5: I'm not convinced that the Data Aggregation attribute is best to have within the network layer. Data aggregation is application specific. The great thing about route-over is that it exposes all of the physical connectivity above IP, and doing so supports the construction of higher-layer structures (i.e. overlays) that can support things like in-network processing. I personally feel that data aggregation is best left for higher layers. > > ==> I agree that data aggregation is application or traffic dependent. Let's hear other's opinion. > > - Section 4.6: I share the same concern with Phil. While even DV protocols maintain neighbors, the strict resource constraints of LLNs often restrict nodes to maintaining state about a *subset* of their neighbors. I do believe that maintaining a node's degree in terms of bi-directional links will not fit within the resource constraints of typical LLNs in the general case. However, degree is a useful metric to have, if we can both define and evaluate it properly. > > ==> As I mentioned already, we need to reach consensus on the way to evaluate node degree. Higher degree would be preferable, but does this apply for all situations? Also, we need to evaluate trade-off between cost and benefit of using node degree as a metric. > > - Section 4.7: Agreeing with what was mentioned earlier on the list, the distinction between Dynamicity (4.7) and Link Reliability (5.2) is not obvious to me. In some sense, we have only marginal control over network topology and node behaviors - they are often driven by surrounding environmental factors. > > ==> we can't control the dynamicity or reliability. We just need to monitor and estimate them to construct a better path by avoiding highly dynamic and unreliable nodes. We need to have clear definitions for them and methods to measure them, which is challenging. > > - Section 5.1: I think the metric we really want here is throughput. Bandwidth is only one of many factor that affects the link's throughput. > > ==> I agree. Actual average data rate can be one factor to affect the throughput. Do you have other factors in your mind? > > - Section 5.2: Just a personal opinion here, but I strongly believe that bi-directional link success rates (PRR) will be much more useful than directional success rates. Due to the lossy nature of LLNs, I expect most, if not all, LLNs to utilize link-layer acknowledgments. Furthermore, enforcing metrics to be bi-directional have significant simplification advantages with respect to routing. > > ===> I do agree, but maintaining bi-directional metrics costs more in terms of communication and other resources like memory and power. > > - Section 5.3: I suggest renaming this attribute to Path Delay to better describe the latency of delivering a message across the entire path. Propagation Delay has already caused some confusion on this list and, as traditionally defined, is fairly insignificant compared to the other causes of delivery delays. > > ===> Here, we try to specify all link attributes as metrics. Of course, path delay impacts more on routing decision, but calculating it costs very high and we need to evaluate all possible paths with global view. I think extending to paths from links is not a good idea when considering routing metrics especially in LLNs due to high costs. > > - Section 5.4: As mentioned with 5.2, bi-directional links are not just important for routing, but to enable the use of link mechanisms such as link-layer acknowledgements. Are there others that feel strongly against preferring routes that support relatively good bi-directional communication? > ===> I do agree that there are good reasons to consider bi-directionality. But we also need to consider costs to maintain it and try to find the best way to figure out and keep it. > > - Section 6: I think it's best to leave the first paragraph in and strike the remaining two. It's useful to give the warning, but we don't have to explain how to address it in this draft. > > ===> I think there is no harm to keep those sentences, which give more information. But we need to revise them, though. > > Jonathan Hui > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 4 02:26:38 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F93728C0F0; Tue, 4 Nov 2008 02:26:38 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A7D28C0F0 for ; Tue, 4 Nov 2008 02:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9psKR9iJSa2f for ; Tue, 4 Nov 2008 02:26:35 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 71EBD3A697E for ; Tue, 4 Nov 2008 02:26:34 -0800 (PST) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id mA4AP0Yx004639 for ; Tue, 4 Nov 2008 11:25:00 +0100 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id D158E10C321 for ; Tue, 4 Nov 2008 11:25:00 +0100 (CET) From: "Mischa Dohler" To: "'ROLL WG'" Date: Tue, 4 Nov 2008 11:21:12 +0100 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <490F6237.8020206@eecs.berkeley.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Ack99WLDtmWpLCU6SEGat/WXCnb0RgAadBkQ Message-Id: <20081104102500.D158E10C321@leo> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Tue, 04 Nov 2008 11:25:00 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Concerning the delay and partially concerning the node degree, just a few minor comments ... - I agree that propagation delay is negligible (and has always been in short range systems; I am not sure why this keeps popping up but my suspicion is that this is a legacy of Kleinrock's/Tobagi's papers). - Also, the processing delay per node will (deterministically) be in the order of a packet length because we are not using transparent forwarding techniques but rather entirely decode and re-encode the packet. I agree with Kris that this will be negligible given other delays. - As for the queuing delay, assume your node runs on an AA battery, then you can calculate that you need a duty cycle of around 1% to make it run for about a decade (taking into account typical battery current leakage models, a typical PHY and a typical MAC). At MAC level this translates to (fairly deterministic) sleep-delays at each node. I hence totally agree with Kris that either this sleep delay is predominant w.r.t. the delay in the scheduling queue or, if you have a powered infrastructure, you can neglect these delays entirely. = - As for the node degree, the duty cycling of the nodes does also allow you to influence the node degree, which should generally be kept fairly low to minimize contention (but sufficiently high to guarantee connectivity). Low node degrees, coupled with low/medium offered traffic which we typically have in WSNs, guarantees that offered traffic is roughly equivalent to the throughput traffic at delays in the order of packet durations. = In summary, I think there won't be so much dynamics associated to the delay in a WSN as compared to ad hoc networks - so no problem, JP. At the same time, the path delay (as mentioned by Jonathan), i.e. the aggregation of delay at each hop from source to sink, can not be neglected and should explicitly be considered, particularly in the case of duty-cycled MACs for delay-constrained applications such as industrial plant applications. It will clearly impact routing solutions since a route with fewer hops might be delay-optimal, even if not energy-optimal. = Best regards, Mischa. _____________________________ Dr Mischa Dohler Senior Researcher CTTC, Barcelona Tel: +34 93 645 2900 Fax: +34 93 645 2901 Mob: +34 6 7909 4007 www.cttc.es/home/mdohler _____________________________ ________________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Kris Pister Sent: Monday, November 03, 2008 9:43 PM To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed JP Vasseur wrote: = Hi Phil, On 10/31/08 5:20 PM, "Philip Levis" wrote: = On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote: = Agree. A good time to ask the question to the WG. Do you think that we need to specify node latency as a metric ? Note that this mean: queueuing delays (per link) and processing time (per node). ps: I=B9m personally very skeptical about using such varying metrics ... W/o high risk of routing oscillations, or we need very carefully designed threshold-based mechanisms certainly no dynamic metrics reflecting =B3real time=B2 values. = Node latency -- the time that passes between packet reception and packet transmission -- can be important but not for either queueing delay or processing time. = That depends ... On the type of nodes, traffic type, ... Etc. Rather, node latency can be important if = there is some kind of underlying scheduling. Or would you consider this queueing delay? = By "underlying scheduling" are you referring to the OS scheduler or the L2 scheduling ? = I don't think that the OS scheduler or any other computation-related delay is likely to cause much trouble. Most/all existing motes can turn a packet around in milliseconds. The L2 access is a much bigger challenge.=A0 Unless you have the luxury of a powered routing infrastructure, one way or the other you'll be duty cycling your receivers.=A0 This will introduce delays of typically hundreds of milliseconds (tens of ms up to seconds). Note that it can differ greatly depending on = which node is the next hop. = But before we start to look at all components, I think that *the* question is whether we want the routing protocol to take into account such highly variable node and link metrics ? = I would love to see a routing protocol that can satisfy our requirements without taking into account the variable node and link metrics.=A0 If we weren't trying to be efficient, then there would be no problem.=A0 But the first L implies that we must be efficient, and the second L makes it very challenging to do that without paying close attention to what's going on at the link level. ksjp Thanks. JP. = = Phil = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 4 03:51:04 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90013A6907; Tue, 4 Nov 2008 03:51:04 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99CB3A6AA5 for ; Tue, 4 Nov 2008 03:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XofAeJvCwcg for ; Tue, 4 Nov 2008 03:51:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7B5073A6A10 for ; Tue, 4 Nov 2008 03:50:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,542,1220227200"; d="scan'208,217";a="26695177" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Nov 2008 11:50:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA4BoaOi008025; Tue, 4 Nov 2008 06:50:36 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA4BoZO7009439; Tue, 4 Nov 2008 11:50:36 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 06:50:35 -0500 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 11:50:35 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 04 Nov 2008 12:50:31 +0100 From: JP Vasseur To: Kris Pister Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack+c4nADcSTdLs9h0Oyky2vlH0qOw== In-Reply-To: <490F6237.8020206@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 11:50:35.0732 (UTC) FILETIME=[8C922940:01C93E73] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10213; t=1225799436; x=1226663436; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Kris=20Pister=20; bh=ruXnWEhPLj02QbTNWYUEKKB02HsvYibGzl+F8Sziwhs=; b=pLrkOTjiWiMu+dMsWBE1iStyd9ni0VnoJQe8MINc1Kd9lJDopcURHnldyT mCd1s2/PZvJ73Uilu3FAWK7Htag1rGQ9hFiabiPREUiUNbPzoycnf6IL05rI ndLEzKY91X; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1661270305==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1661270305== Content-type: multipart/alternative; boundary="B_3308647831_25728595" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308647831_25728595 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Hi Kris, On 11/3/08 9:42 PM, "Kris Pister" wrote: >=20 >=20 > JP Vasseur wrote: >> =20 >> Hi Phil, >>=20 >>=20 >> On 10/31/08 5:20 PM, "Philip Levis" >> wrote: >>=20 >> =20 >> =20 >>> =20 >>> On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote: >>>=20 >>> =20 >>> =20 >>>> =20 >>>> Agree. >>>>=20 >>>> A good time to ask the question to the WG. >>>>=20 >>>> Do you think that we need to specify node latency as a metric ? Note >>>> that this mean: queueuing delays (per link) and processing time (per >>>> node). >>>>=20 >>>> ps: I=A9=F6m personally very skeptical about using such varying >>>> metrics ... W/o high risk of routing oscillations, or we need very >>>> carefully designed threshold-based mechanisms certainly no dynamic >>>> metrics reflecting =A9=F8real time=A9=F7 values. >>>> =20 >>>> =20 >>> =20 >>> Node latency -- the time that passes between packet reception and >>> packet transmission -- can be important but not for either queueing >>> delay or processing time. >>> =20 >>> =20 >> =20 >>=20 >> That depends ... On the type of nodes, traffic type, ... Etc. >>=20 >> Rather, node latency can be important if >> =20 >> =20 >>> =20 >>> there is some kind of underlying scheduling. Or would you consider >>> this queueing delay? >>> =20 >>> =20 >> =20 >>=20 >> By "underlying scheduling" are you referring to the OS scheduler or the = L2 >> scheduling ? >> =20 > I don't think that the OS scheduler or any other computation-related dela= y is > likely to cause much trouble. > Most/all existing motes can turn a packet around in milliseconds. > The L2 access is a much bigger challenge. Unless you have the luxury of = a > powered routing infrastructure, one way or the other you'll be duty cycli= ng > your receivers. This will introduce delays of typically hundreds of > milliseconds (tens of ms up to seconds). >=20 > JP> Makes total sense to me but I wanted to clarify since there are very = few > cases where indeed the node workload may be relevant and may delay packet > forwarding especially with non preempting OS. My personal take on this is= that > the node workload is not significant enough in most of the cases. >> =20 >>=20 >> Note that it can differ greatly depending on >> =20 >> =20 >>> =20 >>> which node is the next hop. >>> =20 >>> =20 >> =20 >>=20 >> But before we start to look at all components, I think that *the* questi= on >> is whether we want the routing protocol to take into account such highly >> variable node and link metrics ? >> =20 > I would love to see a routing protocol that can satisfy our requirements > without taking into account the variable node and link metrics. If we we= ren't > trying to be efficient, then there would be no problem. But the first L > implies that we must be efficient, and the second L makes it very challen= ging > to do that without paying close attention to what's going on at the link > level. >=20 > JP> This is what I wanted to hear explicitly. Can you look at the propose= d > metrics and spell out the link and node metrics that you think are must-h= ave. >=20 > Thanks. >=20 > JP. >=20 > ksjp >> =20 >>=20 >> Thanks. >>=20 >> JP.=20 >>=20 >> =20 >> =20 >>> =20 >>> Phil >>> =20 >>> =20 >> =20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> =20 >=20 --B_3308647831_25728595 Content-type: text/html; charset="EUC-KR" Content-transfer-encoding: quoted-printable Re: [Roll] ROLL Routing Metrics - WF feed-back needed Hi Kris,




On 11/3/08 9:42 PM, "Kris Pister" <pister@eecs.berkeley.edu> wrote:

<= SPAN STYLE=3D'font-size:13pt'>

JP Vasseur wrote:
<= SPAN STYLE=3D'font-size:13pt'>
Hi Phil,


On 10/31/08 5:20 PM, "Philip Levis" <pal@cs.stanford.edu> <ma= ilto:pal@cs.stanford.edu>  wrote:

  
 
<= SPAN STYLE=3D'font-size:13pt'>
On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote:

    
 
<= SPAN STYLE=3D'font-size:13pt'>
Agree.

A good time to ask the question to the WG.

Do you think that we need to specify node latency as a metric ? Note
that this mean: queueuing delays (per link) and processing time (per
node).

ps: I¹m personally very skeptical about using such varying
metrics ... W/o high risk of routing oscillations, or we need very
carefully designed threshold-based mechanisms certainly no dynamic
metrics reflecting ³real time² values.
      
 
=
Node latency -- the time that passes between packet reception and
packet transmission -- can be important but not for either queueing
delay or processing time.
    
 
=

That depends ... On the type of nodes, traffic type, ... Etc.

Rather, node latency can be important if
  
 
<= SPAN STYLE=3D'font-size:13pt'>
there is some kind of underlying scheduling. Or would you consider
this queueing delay?
    
 
=

By "underlying scheduling" are you referring to the OS scheduler = or the L2
scheduling ?
  
= I don't think that the OS scheduler or any othe= r computation-related delay is likely to cause much trouble.
Most/all existing motes can turn a packet around in milliseconds.
The L2 access is a much bigger challenge.  Unless you have the luxury = of a powered routing infrastructure, one way or the other you'll be duty cyc= ling your receivers.  This will introduce delays of typically hundreds = of milliseconds (tens of ms up to seconds).

JP> Makes total sense to me but I wanted to clarif= y since there are very few cases where indeed the node workload may be relev= ant and may delay packet forwarding especially with non preempting OS. My pe= rsonal take on this is that the node workload is not significant enough in m= ost of the cases.


Note that it can differ greatly depending on
  
 
<= SPAN STYLE=3D'font-size:13pt'>
which node is the next hop.
    
 
=

But before we start to look at all components, I think that *the* question<= BR> is whether we want the routing protocol to take into account such highly variable node and link metrics ?
  
= I would love to see a routing protocol that can= satisfy our requirements without taking into account the variable node and = link metrics.  If we weren't trying to be efficient, then there would b= e no problem.  But the first L implies that we must be efficient, and t= he second L makes it very challenging to do that without paying close attent= ion to what's going on at the link level.

JP> This is what I wanted to hear explicitly. Can = you look at the proposed metrics and spell out the link and node metrics tha= t you think are must-have.

Thanks.

JP.

ksjp
<= SPAN STYLE=3D'font-size:13pt'>

Thanks.

JP.

  
 
<= SPAN STYLE=3D'font-size:13pt'>
Phil
    
 
=

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
  
=
--B_3308647831_25728595-- --===============1661270305== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1661270305==-- From roll-bounces@ietf.org Tue Nov 4 03:51:13 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1949328C0FA; Tue, 4 Nov 2008 03:51:13 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350AB28C0FA for ; Tue, 4 Nov 2008 03:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Gkro+pnXGj for ; Tue, 4 Nov 2008 03:51:11 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5B1743A6A00 for ; Tue, 4 Nov 2008 03:51:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,542,1220227200"; d="scan'208";a="26695196" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Nov 2008 11:51:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA4Bp3tB008123; Tue, 4 Nov 2008 06:51:03 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA4Bp32n009538; Tue, 4 Nov 2008 11:51:03 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 06:51:03 -0500 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 11:51:03 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 04 Nov 2008 12:50:53 +0100 From: JP Vasseur To: Jonathan Hui Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack+c5bdAR/qFDydPE2UgEPwz2fjxQ== In-Reply-To: <628C538F-D023-482F-8C94-047D87A49DDC@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 11:51:03.0609 (UTC) FILETIME=[9D2FDA90:01C93E73] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7736; t=1225799463; x=1226663463; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Jonathan=20Hui=20; bh=ydNKuGrb/d+A2vS115wgv78SMWN5UCcKWS46/QQtWGg=; b=UWP44Nwhx9Ugrj0i8wCMgw3Nke7OZLMsDPUt5fhyiavDjMlK3egl+HJ+t4 fbfr9sKAqtfZzX0KoE3QKvYofL5QrLyl5ozv71nWP6aHlxbIKv2Kj9FL96ih x3hZwrzlUs; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan, On 11/3/08 7:02 PM, "Jonathan Hui" wrote: > = > This draft is an excellent starting point and has already generated a > lot of good discussion. Thanks for the comments, Here are some of my own comments: > = > - Section 4.3 and 4.4: I understand that these are important metrics > with more traditional (higher power) link technologies, but I think > the description does not sufficiently characterize the challenges in > LLNs. = JP> Well, except in the case of the "overload" bit used for example for synchronization purposes between the IGP and BGP (due to slower convergence of BGP), these metrics are usually not relevant in traditional networks. In general, most of the high-order bits in these metrics will be > due to communication delays at the link layer (scheduled communication > as well as conservative backoffs can cause communication delays on the > order of seconds and even 10s of seconds). This can easily dwarf all > other delays caused by processing times. For the networks I'm used to > dealing with, I'd argue that communication latency is much more > significant than node workload. JP> We are in sync. As pointed out in previous emails, the goal of this first version was to list *all* metrics and trigger a discussion to make sure that we only keep the *key* metrics. Anyone on this list thinking otherwise with regards to the node workload and latency ? > = > - Section 4.5: I'm not convinced that the Data Aggregation attribute > is best to have within the network layer. Data aggregation is > application specific. The great thing about route-over is that it > exposes all of the physical connectivity above IP, and doing so > supports the construction of higher-layer structures (i.e. overlays) > that can support things like in-network processing. I personally feel > that data aggregation is best left for higher layers. Happy to have that discussion, I do think otherwise ;-) You can always build an overlay at the transport or application layer but that requires to carry extra information in the payload, address manipulations, discovery capabilities (to discover the aggregating nodes), ... Etc. By advertising data aggregation at the routing layer, this allows routing to compute routes taking into account the node aggregation capability, thus the destination remains unchanged and the routing engine potentially elect non shortest paths (=3D> constrained-based routing) to allow for aggregation. > = > - Section 4.6: I share the same concern with Phil. While even DV > protocols maintain neighbors, the strict resource constraints of LLNs > often restrict nodes to maintaining state about a *subset* of their > neighbors. I do believe that maintaining a node's degree in terms of > bi-directional links will not fit within the resource constraints of > typical LLNs in the general case. However, degree is a useful metric > to have, if we can both define and evaluate it properly. OK. Furthermore, the node degree is known in link state and requires significant amount of states in DV, especially when one performs route aggregation. Finally it only gives an "idea" of the potential backup routes. > = > - Section 4.7: Agreeing with what was mentioned earlier on the list, > the distinction between Dynamicity (4.7) and Link Reliability (5.2) > is not obvious to me. In some sense, we have only marginal control > over network topology and node behaviors - they are often driven by > surrounding environmental factors. The idea was to have a simple flag used by a node to advertise (when known) if it is a priori a mobile or static node (e.g. Remote control versus movement detector) whereas the link reliability is not of course related to link quality and can significantly vary on nodes with multiple radios or wired and wireless link. Don't you see a use of such a static/mobile node flag ? > = > - Section 5.1: I think the metric we really want here is throughput. > Bandwidth is only one of many factor that affects the link's throughput. > = Very good point. Totally agree. > - Section 5.2: Just a personal opinion here, but I strongly believe > that bi-directional link success rates (PRR) will be much more useful > than directional success rates. Due to the lossy nature of LLNs, I > expect most, if not all, LLNs to utilize link-layer acknowledgments. > Furthermore, enforcing metrics to be bi-directional have significant > simplification advantages with respect to routing. Mmm ... That does require discussion. Routing is almost always asymmetrical. Why would you need symmetrical link metric for routing ? > = > - Section 5.3: I suggest renaming this attribute to Path Delay to > better describe the latency of delivering a message across the entire > path. = JP> This is typo, yes indeed. Furthermore, Path delay is not a routing metric carried by the protocol. Propagation Delay has already caused some confusion on this list > and, as traditionally defined, is fairly insignificant compared to the > other causes of delivery delays. JP> Which leads to the question: "Do we need link propagation delay at all ?" > = > - Section 5.4: As mentioned with 5.2, bi-directional links are not > just important for routing, but to enable the use of link mechanisms > such as link-layer acknowledgements. Are there others that feel > strongly against preferring routes that support relatively good bi- > directional communication? JP> I do see any reason for mandating path to be symmetrical ? > = > - Section 6: I think it's best to leave the first paragraph in and > strike the remaining two. It's useful to give the warning, but we > don't have to explain how to address it in this draft. JP> Well we do need to discuss these issues in the document. We cannot list a set of metrics without specifying how they will be used and their implication on the routing protocol dynamics. This is one of these examples where the metrics settings is not an implementation issues. I could mention a number of documents where we had to specify such mechanisms in great details to pass IESG review (for good reasons !). Thanks for the comments. Cheers. JP. = > = > -- > Jonathan Hui > = > = > = > On Oct 20, 2008, at 10:14 PM, JP Vasseur wrote: > = >> Dear WG, >> = >> As you know, routing metrics for LLN are part of our WG charter. >> draft-mjkim-roll-routing-metrics-01 is a first draft attempting to >> list a set of link and node metrics candidates. We intentionally >> left a wide set of metrics of various nature: link/node, static/ >> dynamic, ... >> = >> We of course have to be quite careful here: defining metrics is one >> thing, determining what to do and how to make a careful use of it is >> the hard part. There is a number of notorious examples where metrics >> have been defined but have never been used simply for a number of >> reasons: >> =80 Computing an aggregated metric as a polynomial function of a set >> of metrics is too difficult to operate, >> =80 Use of a set of attributes as hierarchical constraints implies >> heavy policy configuration, >> =80 Use of dynamic metrics was the source of routing oscillations >> (e.g. ARPANET) >> =80 .... >> = >> So we would need your feed-back, bearing in mind that we may want to >> only keep the metrics that are critical to LLNs. >> = >> Waiting for your comments ... >> = >> Thanks. >> = >> JP and Kim. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 4 07:22:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0B33A69C5; Tue, 4 Nov 2008 07:22:40 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07543A68B8; Tue, 4 Nov 2008 07:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n61pYv1-mqKs; Tue, 4 Nov 2008 07:22:37 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 7575F3A6921; Tue, 4 Nov 2008 07:22:37 -0800 (PST) Received: from NLHILEXH01.connect1.local (172.16.153.76) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 4 Nov 2008 16:22:41 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH01.connect1.local ([15.143.187.32]) with mapi; Tue, 4 Nov 2008 16:22:33 +0100 From: "Schoofs, Anthony" To: Zach Shelby , 6lowpan <6lowpan@ietf.org>, "roll@ietf.org" Date: Tue, 4 Nov 2008 16:22:30 +0100 Thread-Topic: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] Thread-Index: Ack16O50BPmAtKntR1GV8F9/MK+ztgIp++sg Message-ID: References: <4901E274.4010001@sensinode.com> In-Reply-To: <4901E274.4010001@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Roll] [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Zach, I have a comment regarding the message/option structure of the nd-00 draft. The draft mentions: "The RR contains the addresses the node wants to register, and a possible request for a global assigned address." It seems that the Identity Request option will only be used by LowPAN hosts when they send RRs, and Identity Replies by LowPAN Routers or LowPAN ERs when they send RCs. Therefore sending a RR already indicates that an Address/6lowpan Address option will be an Identity request option, and sending a RC already indicates that an Address/6lowpan Address option will be an Identity Reply option. I would then say that the Identity Request and Identity Reply options are not that necessary, and that you could upgrade Address Option and 6lowpan Address Option as RR/RC options. It would mean small changes in the Address and 6lowpan Address options format to incorporate requisite fields from Identity Request/Reply such as Lifetime and G, P and X flags. Best regards, Anthony -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Friday 24 October 2008 16:58 To: 6lowpan; roll@ietf.org Subject: [6lowpan] [Fwd: New Version Notification fordraft-shelby-6lowpan-nd-00] Hi, The first version of the ND for 6LoWPAN I-D has now been posted and is available for comment. We would appreciate constructive comments and list discussions on this before the IETF, and I would like to request a slot in Minneapolis to present the draft. http://www.ietf.org/internet-drafts/draft-shelby-6lowpan-nd-00.txt There are some known open issues on this draft: o Trickle and its optional use for RA periods in to be in next version. o Fault tolerance to be defined in next version. o Ad-hoc network (no infrastructure) to be discussed in next version. o Context dissemination to be described in more detail. To be determined in how much detail. o Can the 6LoWPAN Address Option be integrated into the Address Option using options in the S field? One less option.. o Consistent for both mesh under and route over may not be 100% consistent yet Regards, Zach -------- Original Message -------- Subject: New Version Notification for draft-shelby-6lowpan-nd-00 Date: Fri, 24 Oct 2008 07:47:19 -0700 (PDT) From: IETF I-D Submission Tool To: zach@sensinode.com CC: pthubert@cisco.com,jhui@archrock.com,samitac@ipinfusion.com,Erik.Nordmark@Sun.COM A new version of I-D, draft-shelby-6lowpan-nd-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository. Filename: draft-shelby-6lowpan-nd Revision: 00 Title: Neighbor Discovery for 6LoWPAN Creation_date: 2008-10-24 WG ID: Independent Submission Number_of_pages: 39 Abstract: The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard ND was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This paper specifies Neighbor Discovery optimized for 6LoWPAN. The IETF Secretariat. -- Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti FINLAND mobile: +358 40 7796297 This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 4 08:16:27 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A3C3A6A43; Tue, 4 Nov 2008 08:16:27 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F2B3A6A43 for ; Tue, 4 Nov 2008 08:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5u2ErA7UEy9 for ; Tue, 4 Nov 2008 08:16:25 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DDCCA3A69F3 for ; Tue, 4 Nov 2008 08:16:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,543,1220227200"; d="scan'208,217";a="100051712" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2008 16:16:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mA4GGNB9019909; Tue, 4 Nov 2008 08:16:23 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mA4GGLTc007709; Tue, 4 Nov 2008 16:16:22 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 11:16:20 -0500 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 16:16:19 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 04 Nov 2008 09:30:57 +0100 From: JP Vasseur To: MiJeom Kim , Philip Levis Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack+V6iwTbxXTerKAEKF+op2aQn4Aw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 16:16:20.0047 (UTC) FILETIME=[AC1F8DF0:01C93E98] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8596; t=1225815383; x=1226679383; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=FihwmhzF/a12RlSPzTvXeTf9ZnwU3MrUqHkwzB4O6YA=; b=QDs2iujQMdjld2V/NMwPVkXLSSxqPy66X5GIGU0m2xkA1yO5Uu8EJDBbGS 6k2B6c57FJ5gfh+vJb4jTk94jv7AbLAwrEcFO2p//UEIzVb0RUJAOZDxKMap joaAA9rpbq; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1659635858==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1659635858== Content-type: multipart/alternative; boundary="B_3308663774_25855075" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308663774_25855075 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: 7bit Hi, On 11/3/08 10:19 AM, "MiJeom Kim" wrote: > Hi, Phil, > > You are absolutely right. I missed link asymmetry. > However, in link state protocols, nodes keep the list of neighbors. > > JP> In link state each node knows the entire topology, thus the set of > neighbors. > > Even in distance vector protocols, I think there is a high chance for nodes to > be aware of their neighbors as time goes. As you mentioned, for constrained > nodes, it might be overhead to keep the neighbor list. But, I don't think it > is very resource consuming to find out the neighbors unless considering very > dynamic networks. > > JP> This is clearly a tradeoff between protocol overhead to keep track of a > list of neighbors (potentially not a negligible amount of data) compared to > what it brings to routing. If the motivation is to compute alternate routes, > there are other technique and the node degree is not sufficient to compute > diverse path anyway so this would at best be used as a heuristic. > > My main concern is whether we need the node degree as a LLN routing metric and > if we do, how we manipulate it. As the document says, it is questionable > whether high node degrees are preferable or not. The decision requires too > many factors need to be considered. Consequently, it's challenging to make use > of node degree as a metric. > > JP> Right. > > So .. I guess that we have a WG consensus not to use it. > > Anybody with a different opinion ? > > Thanks. > > JP. > > Thanks. > Mijeom. > > On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis wrote: >> >> On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: >> >>> >>> 4.6: Is the intention that a node calculates its degree? This is very >>> difficult (some might say impossible under any realistic network scenario). >>> First, it requires O(n^2) communication. The observation that routing >>> protocols might want to change decisions based on density makes sense, but >>> by stating it is a metric that implies nodes calculate it. >>> ===> >>> I think a node can figure out its degree by overhearing. So as time goes, it >>> can get the number of neighbors more precisely. >> >> That would be true if degree were defined as the number of neighbors a node >> can hear. However, it's defined as >> >> Node degree is the number of neighbors that can receive a message >> from the node directly. >> >> Unless you assume asymmetric links do not exist, this requires each node to >> report the set of nodes from which it hears messages, so those nodes can >> calculate their degree. It also requires a node to maintain state linear in >> the number of its neighbors, which is problematic. >> >> Phil > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3308663774_25855075 Content-type: text/html; charset="EUC-KR" Content-transfer-encoding: quoted-printable Re: [Roll] ROLL Routing Metrics - WF feed-back needed Hi,


On 11/3/08 10:19 AM, "MiJeom Kim" <= mijeom@gmail.com> wrote:

H= i, Phil,
You are absolutely right. I missed link asym= metry.
However, in link state protocols, nodes keep the list of neighbors.


Even in distance vector protocols, I think there is a high chance for nodes= to be aware of their neighbors as time goes. As you mentioned, for constrai= ned nodes, it might be overhead to keep the neighbor list. But, I don= 't= think it is very resource consuming to find out the neighbors unless consid= ering very dynamic networks.


My main concern is whether we need the node degre= e as a LLN routing metric and if we do, how we manipulate it. As the documen= t says, it is questionable whether high node degrees are preferable or not. = The decision requires too many factors need to be considered. Consequently, = it's challenging to make use of node= degree as a metric.

JP> Right.

So .. I guess that we have a WG consensus not to use it.

Anybody with a different opinion ?

Thanks.

JP.
Thanks.
Mijeom.

On Sat, Nov 1, 2008 = at 1:13 AM, Philip Levis <pal@cs.stanford.e= du> wrote:

On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote:


4.6: Is the intention that a node calculates its degree? This is very diffi= cult (some might say impossible under any realistic network scenario). First= , it requires O(n^2) communication. The observation that routing protocols m= ight want to change decisions based on density makes sense, but by stating i= t is a metric that implies nodes calculate it.
=3D=3D=3D>
I think a node can figure out its degree by overhearing. So as time goes, i= t can get the number of neighbors more precisely.

That would be true if degree were defined as the number of neighbors a node= can hear. However, it's defined as

  Node degree is the number of neighbors that can receive a messa= ge
  from the node directly.

Unless you assume asymmetric links do not exist, this requires each node to= report the set of nodes from which it hears messages, so those nodes can ca= lculate their degree. It also requires a node to maintain state linear in th= e number of its neighbors, which is problematic.

Phil


___________= ____________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
--B_3308663774_25855075-- --===============1659635858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1659635858==-- From roll-bounces@ietf.org Tue Nov 4 10:16:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC9A28C155; Tue, 4 Nov 2008 10:16:39 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF7D28C155 for ; Tue, 4 Nov 2008 10:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJeSGQTnf7pq for ; Tue, 4 Nov 2008 10:16:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7E8D33A696E for ; Tue, 4 Nov 2008 10:16:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,544,1220227200"; d="scan'208";a="26706584" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Nov 2008 18:16:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA4IGYx0029694; Tue, 4 Nov 2008 13:16:34 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mA4IGYXu027592; Tue, 4 Nov 2008 18:16:34 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 13:16:34 -0500 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Nov 2008 18:16:34 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Tue, 04 Nov 2008 19:16:29 +0100 From: JP Vasseur To: Kris Pister Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack+qXT+vkenPxKl/kWnq92tlUafWQ== In-Reply-To: <490FDD77.7000205@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 18:16:34.0615 (UTC) FILETIME=[78574470:01C93EA9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4711; t=1225822594; x=1226686594; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Kris=20Pister=20; bh=DyG7OWDHuycms/7nWapjuzpJwU5iA5ra0TkfnAbYBdU=; b=Yioian27t+c2VV98BRaubq+BJCyeuoVWPuTjDCgF/NVjcjQGUC/sm6xjMA d/tAgFJmsJN6lkzDXbq1RN3gCKslTpAD3aLAViAmOHo1dVMDMCCOPkfqMsTd /f6dx6Xv5Q; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Kris, On 11/4/08 6:28 AM, "Kris Pister" wrote: > JP - I'd like to understand more about your flags. > If I have a network in which I expect that all motes last for 7 years, > where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 > years)? At 5% (ideally 3 months)? > In the first case, for roughly half of my network lifetime, all of my > network will have set the "I'm low on energy" flag, and I will have no > useful information with which to make routing decisions. > In the second case, I have almost no useful information until it's too > late - one year into operation and several of the busiest motes are > almost dead, while a mote with a much bigger battery still has almost > all of it's charge. So in this case the information shows up too late > to be useful. > I'm sure that's not the way you see it. What am I missing? > See it as a trade-off between frequent accurate updates (=> requiring energy, risk of routing oscillations, ...) and no information at all. If you make the assumption of uniform energy consumption, then flags are always useless (so does more up to date data). On the other hand if you see the use of such flags as safeguard mechanisms, this could be useful to start rerouting the traffic around nodes running out of battery. Suppose that the traffic is not equally balanced in the network, you may end up with nodes consuming battery at a much higher rates than others, in which case the flags may be useful, with no risk of oscillation. Thoughts ? Cheers, JP. > ksjp > > JP Vasseur wrote: >> Hi Miguel, >> >> >> On 10/31/08 12:24 PM, "Miguel Sanchez" wrote: >> >> >>> Hi JP, >>> >>> >>> >>> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur wrote: >>> >>>> Hi Kris, >>>> >>>> >>>> On 10/30/08 5:33 PM, "Kris Pister" wrote: >>>> >>>> I agree with Miguel that we need a standard way of energy reporting, and I >>>> agree with JP that it's hard to do. >>>> Part of the challenge is that energy sources and storage vary so much. We >>>> have: >>>> * line power - great if you can get it! >>>> * battery storage >>>> - this is time varying. The available energy in a battery is a >>>> strong >>>> function of the temperature and the usage profile. So a battery powered >>>> mote may correctly calculate five years of lifetime in summer, and then >>>> that >>>> winter under the exact same load conditions it may correctly calculate a >>>> lifetime of ten years. The same mote with the same battery may have better >>>> performance in summer at higher loads. >>>> >>>> JP> and usage profile may also change. >>>> >>>> * capacitive storage >>>> * energy scavenging >>>> - this is time varying, and tough to bound (usefully >>>> >>>> JP> this is why I'm questioning the usefulness of knowing the remaining >>>> energy expressed in Joules or other metrics. Knowing this value will not >>>> tell you anything as to whether you should or should not use that node when >>>> computing the path. Another metric may be the remaining estimated lifetime >>>> >>> I disagree. >>> >>> At least if remaining energy is infinitum (mains powered) tells you >>> something. >>> >>> OTOH, if limited, depending on other properties of the nodes (like >>> where it gets its energy from) it is also useful for making routing >>> decisions too. >>> >> >> OK let's try to step back. I'm proposing a flag-based mechanism to avoid the >> use of a node should this node run out of energy. The decision to set the >> flag is made by the node (no specified) according to many parameters >> (estimated like time, ... Etc). Some nodes having more power may make use of >> complex models. >> >> If you advertise your remaining power in Joules, how would you expect the >> nodes to change their routing decisions since they have no idea of whether >> you are running low in energy (it highly depends on what the node does, the >> external conditions, ... Etc) ? >> >> Thanks. >> >> JP. >> >> >>>> but still, is the node capable (without consuming too much energy) of >>>> gathering historical data etc ... to provide an accurate value hoping that >>>> other criterion such as usage profile or temperature as you pointed out >>>> will >>>> not change ? >>>> >>>> All of this makes energy/power/lifetime reporting painful, yet I can not >>>> picture a successful routing protocol that doesn't somehow take these >>>> factors into account. >>>> >>>> >>> Kind regards, >>> >>> Miguel >>> >> >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 4 16:06:15 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8D13A67BD; Tue, 4 Nov 2008 16:06:15 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33043A67BD for ; Tue, 4 Nov 2008 16:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-JRKRSpXtuM for ; Tue, 4 Nov 2008 16:06:12 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 9A3E33A67AF for ; Tue, 4 Nov 2008 16:06:12 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mA505oOp026052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Nov 2008 16:06:01 -0800 (PST) Message-ID: <4910E358.1030205@eecs.berkeley.edu> Date: Tue, 04 Nov 2008 16:05:44 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1849547081==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1849547081== Content-Type: multipart/alternative; boundary="------------070908090800050408080305" This is a multi-part message in MIME format. --------------070908090800050408080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well, we both agree that there will be load imbalance and differential rate of energy consumption, and we both agree that oscillations will be bad. I think that we may have a different picture of the frequency of those oscillations, though. I think that most/all of the systems described in the requirements docs have battery lifetime requirements measured in years. This implies a minimum update rate of, oh, something like monthly. Sending a few tens of bytes of data describing energy and power state on a daily basis is both far more frequent than we need, and unlikely to cause *wasteful* oscillations. If there is some route bouncing with a one day or week period, maybe that's actually optimal. It's certainly not expensive. I'm still very curious as to where you think that we should set the "low energy" flag level. Based on the two scenarios that I presented, I don't see that single-bit flags have much value. As you pointed out in your response, the traffic will not be balanced. Either I set the flag near midpoint, and it doesn't help much, or I set well below midpoint, and it doesn't help very much. I can imagine scenarios in which it works great. Unfortunately, working well 50% of the time doesn't do us much good. We don't have to handle every situation, but we have to at least deal with common problems that come up in real networks. ksjp JP Vasseur wrote: > Hi Kris, > > > On 11/4/08 6:28 AM, "Kris Pister" wrote: > > >> JP - I'd like to understand more about your flags. >> If I have a network in which I expect that all motes last for 7 years, >> where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 >> years)? At 5% (ideally 3 months)? >> In the first case, for roughly half of my network lifetime, all of my >> network will have set the "I'm low on energy" flag, and I will have no >> useful information with which to make routing decisions. >> In the second case, I have almost no useful information until it's too >> late - one year into operation and several of the busiest motes are >> almost dead, while a mote with a much bigger battery still has almost >> all of it's charge. So in this case the information shows up too late >> to be useful. >> I'm sure that's not the way you see it. What am I missing? >> >> > > See it as a trade-off between frequent accurate updates (=> requiring > energy, risk of routing oscillations, ...) and no information at all. If you > make the assumption of uniform energy consumption, then flags are always > useless (so does more up to date data). On the other hand if you see the use > of such flags as safeguard mechanisms, this could be useful to start > rerouting the traffic around nodes running out of battery. Suppose that the > traffic is not equally balanced in the network, you may end up with nodes > consuming battery at a much higher rates than others, in which case the > flags may be useful, with no risk of oscillation. > > Thoughts ? > > Cheers, > > JP. > > >> ksjp >> >> JP Vasseur wrote: >> >>> Hi Miguel, >>> >>> >>> On 10/31/08 12:24 PM, "Miguel Sanchez" wrote: >>> >>> >>> >>>> Hi JP, >>>> >>>> >>>> >>>> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur wrote: >>>> >>>> >>>>> Hi Kris, >>>>> >>>>> >>>>> On 10/30/08 5:33 PM, "Kris Pister" wrote: >>>>> >>>>> I agree with Miguel that we need a standard way of energy reporting, and I >>>>> agree with JP that it's hard to do. >>>>> Part of the challenge is that energy sources and storage vary so much. We >>>>> have: >>>>> * line power - great if you can get it! >>>>> * battery storage >>>>> - this is time varying. The available energy in a battery is a >>>>> strong >>>>> function of the temperature and the usage profile. So a battery powered >>>>> mote may correctly calculate five years of lifetime in summer, and then >>>>> that >>>>> winter under the exact same load conditions it may correctly calculate a >>>>> lifetime of ten years. The same mote with the same battery may have better >>>>> performance in summer at higher loads. >>>>> >>>>> JP> and usage profile may also change. >>>>> >>>>> * capacitive storage >>>>> * energy scavenging >>>>> - this is time varying, and tough to bound (usefully >>>>> >>>>> JP> this is why I'm questioning the usefulness of knowing the remaining >>>>> energy expressed in Joules or other metrics. Knowing this value will not >>>>> tell you anything as to whether you should or should not use that node when >>>>> computing the path. Another metric may be the remaining estimated lifetime >>>>> >>>>> >>>> I disagree. >>>> >>>> At least if remaining energy is infinitum (mains powered) tells you >>>> something. >>>> >>>> OTOH, if limited, depending on other properties of the nodes (like >>>> where it gets its energy from) it is also useful for making routing >>>> decisions too. >>>> >>>> >>> OK let's try to step back. I'm proposing a flag-based mechanism to avoid the >>> use of a node should this node run out of energy. The decision to set the >>> flag is made by the node (no specified) according to many parameters >>> (estimated like time, ... Etc). Some nodes having more power may make use of >>> complex models. >>> >>> If you advertise your remaining power in Joules, how would you expect the >>> nodes to change their routing decisions since they have no idea of whether >>> you are running low in energy (it highly depends on what the node does, the >>> external conditions, ... Etc) ? >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>>>> but still, is the node capable (without consuming too much energy) of >>>>> gathering historical data etc ... to provide an accurate value hoping that >>>>> other criterion such as usage profile or temperature as you pointed out >>>>> will >>>>> not change ? >>>>> >>>>> All of this makes energy/power/lifetime reporting painful, yet I can not >>>>> picture a successful routing protocol that doesn't somehow take these >>>>> factors into account. >>>>> >>>>> >>>>> >>>> Kind regards, >>>> >>>> Miguel >>>> >>>> >>> >>> > > --------------070908090800050408080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, we both agree that there will be load imbalance and differential rate of energy consumption,
and we both agree that oscillations will be bad.  I think that we may have a different picture of the
frequency of those oscillations, though.  I think that most/all of the systems described in the
requirements docs have battery lifetime requirements measured in years.  This implies a minimum
update rate of, oh, something like monthly.  Sending a few tens of bytes of data describing
energy and power state on a daily basis is both far more frequent than we need, and unlikely
to cause *wasteful* oscillations.  If there is some route bouncing with a one day or week period, maybe
that's actually optimal.  It's certainly not expensive.

I'm still very curious as to where you think that we should set the "low energy" flag level.  Based on the two scenarios that I presented, I don't see that single-bit flags have much value.  As you pointed out in your response, the traffic will not be balanced.  Either I set the flag near midpoint, and it doesn't help much, or I set well below midpoint, and it doesn't help very much.

I can imagine scenarios in which it works great.  Unfortunately, working well 50% of the time doesn't do us much good.  We don't have to handle every situation, but we have to at least deal with common problems that come up in real networks.

ksjp

JP Vasseur wrote: 
Hi Kris,


On 11/4/08 6:28 AM, "Kris Pister" <pister@eecs.berkeley.edu> wrote:

  
JP - I'd like to understand more about your flags.
If I have a network in which I expect that all motes last for 7 years,
where do I set the "I'm low on energy" flag?  At 50% (ideally 3.5
years)?  At 5% (ideally 3 months)?
In the first case, for roughly half of my network lifetime, all of my
network will have set the "I'm low on energy" flag, and I will have no
useful information with which to make routing decisions.
In the second case, I have almost no useful information until it's too
late - one year into operation and several of the busiest motes are
almost dead, while a mote with a much bigger battery still has almost
all of it's charge.  So in this case the information shows up too late
to be useful.
I'm sure that's not the way you see it.  What am I missing?

    

See it as a trade-off between frequent accurate updates (=> requiring
energy, risk of routing oscillations, ...) and no information at all. If you
make the assumption of uniform energy consumption, then flags are always
useless (so does more up to date data). On the other hand if you see the use
of such flags as safeguard mechanisms, this could be useful to start
rerouting the traffic around nodes running out of battery. Suppose that the
traffic is not equally balanced in the network, you may end up with nodes
consuming battery at a much higher rates than others, in which case the
flags may be useful, with no risk of oscillation.

Thoughts ?

Cheers,

JP. 

  
ksjp

JP Vasseur wrote:
    
Hi Miguel,


On 10/31/08 12:24 PM, "Miguel Sanchez" <misan@disca.upv.es> wrote:

  
      
Hi JP,



On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur <jvasseur@cisco.com> wrote:
    
        
Hi Kris,


On 10/30/08 5:33 PM, "Kris Pister" <pister@eecs.berkeley.edu> wrote:

I agree with Miguel that we need a standard way of energy reporting, and I
agree with JP that it's hard to do.
Part of the challenge is that energy sources and storage vary so much. We
have:
 * line power - great if you can get it!
 * battery storage
      - this is time varying.  The available energy in a battery is a
strong
function of the temperature and the usage profile.  So a battery powered
mote may correctly calculate five years of lifetime in summer, and then
that
winter under the exact same load conditions it may correctly calculate a
lifetime of ten years.  The same mote with the same battery may have better
performance in summer at higher loads.

JP> and usage profile may also change.

 * capacitive storage
 * energy scavenging
      - this is time varying, and tough to bound (usefully

JP> this is why I'm questioning the usefulness of knowing the remaining
energy expressed in Joules or other metrics. Knowing this value will not
tell you anything as to whether you should or should not use that node when
computing the path. Another metric may be the remaining estimated lifetime
      
          
I disagree.

At least if remaining energy is infinitum (mains powered) tells you
something.

OTOH, if limited, depending on other properties of the nodes (like
where it gets its energy from) it is also useful for making routing
decisions too.
    
        
OK let's try to step back. I'm proposing a flag-based mechanism to avoid the
use of a node should this node run out of energy. The decision to set the
flag is made by the node (no specified) according to many parameters
(estimated like time, ... Etc). Some nodes having more power may make use of
complex models.

If you advertise your remaining power in Joules, how would you expect the
nodes to change their routing decisions since they have no idea of whether
you are running low in energy (it highly depends on what the node does, the
external conditions, ... Etc) ?

Thanks.

JP.

  
      
but still, is the node capable (without consuming too much energy) of
gathering historical data etc ... to provide an accurate value hoping that
other criterion such as usage profile or temperature as you pointed out
will
not change ?

All of this makes energy/power/lifetime reporting painful, yet I can not
picture a successful routing protocol that doesn't somehow take these
factors into account.

      
          
Kind regards,

Miguel
--------------070908090800050408080305-- --===============1849547081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1849547081==-- From roll-bounces@ietf.org Wed Nov 5 00:58:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9F63A6A3D; Wed, 5 Nov 2008 00:58:19 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30813A6A3D for ; Wed, 5 Nov 2008 00:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8VWFD8zD3+c for ; Wed, 5 Nov 2008 00:58:15 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0F1DC3A68EF for ; Wed, 5 Nov 2008 00:58:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,549,1220227200"; d="scan'208,217";a="26801390" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Nov 2008 08:57:54 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA58vsYH030998; Wed, 5 Nov 2008 03:57:54 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mA58vsqm013096; Wed, 5 Nov 2008 08:57:54 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 03:57:54 -0500 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Nov 2008 08:57:53 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 05 Nov 2008 09:57:46 +0100 From: JP Vasseur To: Kris Pister Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack/JJIkMj6fFEoeTU2Btx1F3b2KkQ== In-Reply-To: <4910E358.1030205@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 05 Nov 2008 08:57:54.0419 (UTC) FILETIME=[97290430:01C93F24] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=19912; t=1225875474; x=1226739474; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Kris=20Pister=20; bh=wZYPO4qkQTp/U2T6TS6xTWvq853laBX/GksGryQWTF0=; b=xJ1UH8Zt9NaaAAwPM3+wjABvu8rVVAswTRROyqipiokz200AEoL2aCZJNy MrlHslSGQzm4ZeSkZ1vxgVAbKw0kSGk85cG55Nb8fHSKLQK9IKiumOEcy3Ph P+S/ZBFe7n; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0048031900==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0048031900== Content-type: multipart/alternative; boundary="B_3308723867_419059" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308723867_419059 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Kris, On 11/5/08 1:05 AM, "Kris Pister" wrote: > Well, we both agree that there will be load imbalance and differential rate of > energy consumption, > and we both agree that oscillations will be bad. > > JP> Indeed. > > I think that we may have a different picture of the > frequency of those oscillations, though. I think that most/all of the systems > described in the > requirements docs have battery lifetime requirements measured in years. This > implies a minimum > update rate of, oh, something like monthly. Sending a few tens of bytes of > data describing > energy and power state on a daily basis is both far more frequent than we > need, and unlikely > to cause *wasteful* oscillations. > > JP> Also agreeing. > > If there is some route bouncing with a one day or week period, maybe > that's actually optimal. It's certainly not expensive. > > I'm still very curious as to where you think that we should set the "low > energy" flag level. Based on the two scenarios that I presented, I don't see > that single-bit flags have much value. As you pointed out in your response, > the traffic will not be balanced. Either I set the flag near midpoint, and it > doesn't help much, or I set well below midpoint, and it doesn't help very > much. > > I can imagine scenarios in which it works great. > > JP> So do I. > > Unfortunately, working well 50% of the time doesn't do us much good. We don't > have to handle every situation, but we have to at least deal with common > problems that come up in real networks. > > JP> I was actually referring to 2 levels of flagging providing enough > flexibility ... But we can think of using a more accurate model with higher > granularity. I personally think that the number of metrics specified in WHART > is too high, may be a 2-flag mechanism may be too coarse. Then we will have to > also specify how often to set these metrics since this is not in this case an > implementation issue. We will also have to specify how to compute those > metrics. > > Can we try to find a middle ground solution ? > > Cheers. > > JP. > > ksjp > > JP Vasseur wrote: >> >> Hi Kris, >> >> >> On 11/4/08 6:28 AM, "Kris Pister" >> wrote: >> >> >> >>> >>> JP - I'd like to understand more about your flags. >>> If I have a network in which I expect that all motes last for 7 years, >>> where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 >>> years)? At 5% (ideally 3 months)? >>> In the first case, for roughly half of my network lifetime, all of my >>> network will have set the "I'm low on energy" flag, and I will have no >>> useful information with which to make routing decisions. >>> In the second case, I have almost no useful information until it's too >>> late - one year into operation and several of the busiest motes are >>> almost dead, while a mote with a much bigger battery still has almost >>> all of it's charge. So in this case the information shows up too late >>> to be useful. >>> I'm sure that's not the way you see it. What am I missing? >>> >>> >>> >> >> >> See it as a trade-off between frequent accurate updates (=> requiring >> energy, risk of routing oscillations, ...) and no information at all. If you >> make the assumption of uniform energy consumption, then flags are always >> useless (so does more up to date data). On the other hand if you see the use >> of such flags as safeguard mechanisms, this could be useful to start >> rerouting the traffic around nodes running out of battery. Suppose that the >> traffic is not equally balanced in the network, you may end up with nodes >> consuming battery at a much higher rates than others, in which case the >> flags may be useful, with no risk of oscillation. >> >> Thoughts ? >> >> Cheers, >> >> JP. >> >> >> >>> >>> ksjp >>> >>> JP Vasseur wrote: >>> >>> >>>> >>>> Hi Miguel, >>>> >>>> >>>> On 10/31/08 12:24 PM, "Miguel Sanchez" >>>> wrote: >>>> >>>> >>>> >>>> >>>>> >>>>> Hi JP, >>>>> >>>>> >>>>> >>>>> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> Hi Kris, >>>>>> >>>>>> >>>>>> On 10/30/08 5:33 PM, "Kris Pister" >>>>>> wrote: >>>>>> >>>>>> I agree with Miguel that we need a standard way of energy reporting, and >>>>>> I >>>>>> agree with JP that it's hard to do. >>>>>> Part of the challenge is that energy sources and storage vary so much. We >>>>>> have: >>>>>> * line power - great if you can get it! >>>>>> * battery storage >>>>>> - this is time varying. The available energy in a battery is a >>>>>> strong >>>>>> function of the temperature and the usage profile. So a battery powered >>>>>> mote may correctly calculate five years of lifetime in summer, and then >>>>>> that >>>>>> winter under the exact same load conditions it may correctly calculate a >>>>>> lifetime of ten years. The same mote with the same battery may have >>>>>> better >>>>>> performance in summer at higher loads. >>>>>> >>>>>> JP> and usage profile may also change. >>>>>> >>>>>> * capacitive storage >>>>>> * energy scavenging >>>>>> - this is time varying, and tough to bound (usefully >>>>>> >>>>>> JP> this is why I'm questioning the usefulness of knowing the remaining >>>>>> energy expressed in Joules or other metrics. Knowing this value will not >>>>>> tell you anything as to whether you should or should not use that node >>>>>> when >>>>>> computing the path. Another metric may be the remaining estimated >>>>>> lifetime >>>>>> >>>>>> >>>>>> >>>>> >>>>> I disagree. >>>>> >>>>> At least if remaining energy is infinitum (mains powered) tells you >>>>> something. >>>>> >>>>> OTOH, if limited, depending on other properties of the nodes (like >>>>> where it gets its energy from) it is also useful for making routing >>>>> decisions too. >>>>> >>>>> >>>>> >>>> >>>> OK let's try to step back. I'm proposing a flag-based mechanism to avoid >>>> the >>>> use of a node should this node run out of energy. The decision to set the >>>> flag is made by the node (no specified) according to many parameters >>>> (estimated like time, ... Etc). Some nodes having more power may make use >>>> of >>>> complex models. >>>> >>>> If you advertise your remaining power in Joules, how would you expect the >>>> nodes to change their routing decisions since they have no idea of whether >>>> you are running low in energy (it highly depends on what the node does, the >>>> external conditions, ... Etc) ? >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> but still, is the node capable (without consuming too much energy) of >>>>>> gathering historical data etc ... to provide an accurate value hoping >>>>>> that >>>>>> other criterion such as usage profile or temperature as you pointed out >>>>>> will >>>>>> not change ? >>>>>> >>>>>> All of this makes energy/power/lifetime reporting painful, yet I can not >>>>>> picture a successful routing protocol that doesn't somehow take these >>>>>> factors into account. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3308723867_419059 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Roll] ROLL Routing Metrics - WF feed-back needed Hi Kris,

On 11/5/08 1:05 AM, "Kris Pister" <pister@eecs.berkeley.edu> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Well, we both agree that there will be load imba= lance and differential rate of energy consumption,
and we both agree that oscillations will be bad.  

JP> Indeed.

I think that we may have a different picture of the
frequency of those oscillations, though.  I think that most/all of the= systems described in the
requirements docs have battery lifetime requirements measured in years. &nb= sp;This implies a minimum
update rate of, oh, something like monthly.  Sending a few tens of byt= es of data describing
energy and power state on a daily basis is both far more frequent than we n= eed, and unlikely
to cause *wasteful* oscillations.  

JP> Also agreeing.

If there is some route bouncing with a one day or week period, maybe
that's actually optimal.  It's certainly not expensive.

I'm still very curious as to where you think that we should set the "l= ow energy" flag level.  Based on the two scenarios that I presente= d, I don't see that single-bit flags have much value.  As you pointed o= ut in your response, the traffic will not be balanced.  Either I set th= e flag near midpoint, and it doesn't help much, or I set well below midpoint= , and it doesn't help very much.

I can imagine scenarios in which it works great.  

JP> So do I.

Unfortunately, working well 50% of the time doesn't do us much good.  = We don't have to handle every situation, but we have to at least deal with c= ommon problems that come up in real networks.

JP>  I was actually referring to 2 levels of = flagging providing enough flexibility ... But we can think of using a more a= ccurate model with higher granularity. I personally think that the number of= metrics specified in WHART is too high, may be a 2-flag mechanism may be to= o coarse. Then we will have to also specify how often to set these metrics s= ince this is not in this case an implementation issue. We will also have to = specify how to compute those metrics.

Can we try to find a middle ground solution ?

Cheers.

JP.

ksjp

JP Vasseur wrote:
<= SPAN STYLE=3D'font-size:13pt'>
Hi Kris,


On 11/4/08 6:28 AM, "Kris Pister" <pister@eecs.berkeley.edu> <mailto:pister@eecs.berkeley.edu>  wrote:

  
 
<= SPAN STYLE=3D'font-size:13pt'>
JP - I'd like to understand more about your flags.
If I have a network in which I expect that all motes last for 7 years,
where do I set the "I'm low on energy" flag?  At 50% (ideall= y 3.5
years)?  At 5% (ideally 3 months)?
In the first case, for roughly half of my network lifetime, all of my
network will have set the "I'm low on energy" flag, and I will ha= ve no
useful information with which to make routing decisions.
In the second case, I have almost no useful information until it's too
late - one year into operation and several of the busiest motes are
almost dead, while a mote with a much bigger battery still has almost
all of it's charge.  So in this case the information shows up too late=
to be useful.
I'm sure that's not the way you see it.  What am I missing?

    
 
=

See it as a trade-off between frequent accurate updates (=3D> requiring energy, risk of routing oscillations, ...) and no information at all. If yo= u
make the assumption of uniform energy consumption, then flags are always useless (so does more up to date data). On the other hand if you see the us= e
of such flags as safeguard mechanisms, this could be useful to start
rerouting the traffic around nodes running out of battery. Suppose that the=
traffic is not equally balanced in the network, you may end up with nodes consuming battery at a much higher rates than others, in which case the
flags may be useful, with no risk of oscillation.

Thoughts ?

Cheers,

JP.

  
 
<= SPAN STYLE=3D'font-size:13pt'>
ksjp

JP Vasseur wrote:
    
 
<= SPAN STYLE=3D'font-size:13pt'>
Hi Miguel,


On 10/31/08 12:24 PM, "Miguel Sanchez" <misan@disca.upv.es> <ma= ilto:misan@disca.upv.es>  wrote:

  
      
 
<= SPAN STYLE=3D'font-size:13pt'>
Hi JP,



On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur <jvasseur@cisco.com> <mailto= :jvasseur@cisco.com>  wrote:
    
        
 
<= SPAN STYLE=3D'font-size:13pt'>
Hi Kris,


On 10/30/08 5:33 PM, "Kris Pister" <pister@eecs.berkeley.edu> <mailto:pister@eecs.berkeley.edu>  wrote:

I agree with Miguel that we need a standard way of energy reporting, and I<= BR> agree with JP that it's hard to do.
Part of the challenge is that energy sources and storage vary so much. We have:
 * line power - great if you can get it!
 * battery storage
      - this is time varying.  The avail= able energy in a battery is a
strong
function of the temperature and the usage profile.  So a battery power= ed
mote may correctly calculate five years of lifetime in summer, and then
that
winter under the exact same load conditions it may correctly calculate a lifetime of ten years.  The same mote with the same battery may have b= etter
performance in summer at higher loads.

JP> and usage profile may also change.

 * capacitive storage
 * energy scavenging
      - this is time varying, and tough to bo= und (usefully

JP> this is why I'm questioning the usefulness of knowing the remaining<= BR> energy expressed in Joules or other metrics. Knowing this value will not tell you anything as to whether you should or should not use that node when=
computing the path. Another metric may be the remaining estimated lifetime<= BR>       
          
 
=
I disagree.

At least if remaining energy is infinitum (mains powered) tells you
something.

OTOH, if limited, depending on other properties of the nodes (like
where it gets its energy from) it is also useful for making routing
decisions too.
    
        
 
=
OK let's try to step back. I'm proposing a flag-based mechanism to avoid th= e
use of a node should this node run out of energy. The decision to set the flag is made by the node (no specified) according to many parameters
(estimated like time, ... Etc). Some nodes having more power may make use o= f
complex models.

If you advertise your remaining power in Joules, how would you expect the nodes to change their routing decisions since they have no idea of whether<= BR> you are running low in energy (it highly depends on what the node does, the=
external conditions, ... Etc) ?

Thanks.

JP.

  
      
 
<= SPAN STYLE=3D'font-size:13pt'>
<= SPAN STYLE=3D'font-size:13pt'>
but still, is the node capable (without consuming too much energy) of
gathering historical data etc ... to provide an accurate value hoping that<= BR> other criterion such as usage profile or temperature as you pointed out
will
not change ?

All of this makes energy/power/lifetime reporting painful, yet I can not picture a successful routing protocol that doesn't somehow take these
factors into account.

      
          
 
=
Kind regards,

Miguel
    
        
 
=
  
      
 
=
=

  
=
___________= ____________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
--B_3308723867_419059-- --===============0048031900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0048031900==-- From roll-bounces@ietf.org Wed Nov 5 01:14:05 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA0E3A68BE; Wed, 5 Nov 2008 01:14:05 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D083A67A6 for ; Wed, 5 Nov 2008 01:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9YMZs3pzVck for ; Wed, 5 Nov 2008 01:13:58 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 24E343A68BE for ; Wed, 5 Nov 2008 01:13:58 -0800 (PST) Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 5 Nov 2008 10:13:59 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Wed, 5 Nov 2008 10:13:53 +0100 From: "Schoofs, Anthony" To: JP Vasseur , MiJeom Kim , Philip Levis Date: Wed, 5 Nov 2008 10:12:27 +0100 Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack+V6iwTbxXTerKAEKF+op2aQn4AwAzqftA Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nl-NL MIME-Version: 1.0 Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0135220545==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0135220545== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A66C224427093F49B30AFFD4A642197F820D0D9296NLCLUEXM03con_" --_000_A66C224427093F49B30AFFD4A642197F820D0D9296NLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In 6lowPAN networks, a node may be able to calculate its degree thanks to 6= lowpan Neighbor Discovery mechanisms. LowPAN routers could know how many nodes are surrounding them via Router So= licitations and Router Registration messages they receive from neighboring = nodes. Because these mechanisms are repeated periodically, LowPAN Routers may be a= ble to maintain a "fresh" node degree without having to generate extra pack= ets. Best regards, Anthony ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur Sent: Tuesday 4 November 2008 9:31 To: MiJeom Kim; Philip Levis Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Hi, On 11/3/08 10:19 AM, "MiJeom Kim" wrote: Hi, Phil, You are absolutely right. I missed link asymmetry. However, in link state protocols, nodes keep the list of neighbors. JP> In link state each node knows the entire topology, thus the set of neig= hbors. Even in distance vector protocols, I think there is a high chance for nodes= to be aware of their neighbors as time goes. As you mentioned, for constra= ined nodes, it might be overhead to keep the neighbor list. But, I don't th= ink it is very resource consuming to find out the neighbors unless consider= ing very dynamic networks. JP> This is clearly a tradeoff between protocol overhead to keep track of a= list of neighbors (potentially not a negligible amount of data) compared t= o what it brings to routing. If the motivation is to compute alternate rout= es, there are other technique and the node degree is not sufficient to comp= ute diverse path anyway so this would at best be used as a heuristic. My main concern is whether we need the node degree as a LLN routing metric = and if we do, how we manipulate it. As the document says, it is questionabl= e whether high node degrees are preferable or not. The decision requires to= o many factors need to be considered. Consequently, it's challenging to mak= e use of node degree as a metric. JP> Right. So .. I guess that we have a WG consensus not to use it. Anybody with a different opinion ? Thanks. JP. Thanks. Mijeom. On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis wrote: On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: 4.6: Is the intention that a node calculates its degree? This is very diffi= cult (some might say impossible under any realistic network scenario). Firs= t, it requires O(n^2) communication. The observation that routing protocols= might want to change decisions based on density makes sense, but by statin= g it is a metric that implies nodes calculate it. =3D=3D=3D> I think a node can figure out its degree by overhearing. So as time goes, i= t can get the number of neighbors more precisely. That would be true if degree were defined as the number of neighbors a node= can hear. However, it's defined as Node degree is the number of neighbors that can receive a message from the node directly. Unless you assume asymmetric links do not exist, this requires each node to= report the set of nodes from which it hears messages, so those nodes can c= alculate their degree. It also requires a node to maintain state linear in = the number of its neighbors, which is problematic. Phil ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A66C224427093F49B30AFFD4A642197F820D0D9296NLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Roll] ROLL Routing Metrics - WF feed-back needed

In 6lowPAN networks, a node may be abl= e to calculate its degree thanks to 6lowpan Neighbor Discovery mec= hanisms.

LowPAN routers could know how many nod= es are surrounding them via Router Solicitations and Router Registration me= ssages they receive from neighboring nodes.

Because these mechanisms are repeated = periodically, LowPAN Routers may be able to maintain a “fresh” = node degree without having to generate extra packets.

 

Best regards,=

Anthony

 

 

From: roll= -bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: Tuesday 4 November 200= 8 9:31
To: MiJeom Kim; Philip Levis=
Cc: ROLL WG
Subject: Re: [Roll] ROLL Rou= ting Metrics - WF feed-back needed

 

Hi,


On 11/3/08 10:19 AM, "MiJeom Kim" <mijeom@gmail.com> wrote:

Hi, Phil,

You are absolutely right. I missed link asymmetry.
However, in link state protocols, nodes keep the list of neighbors.

JP> In link state each node kn= ows the entire topology, thus the set of neighbors.

Even in distance vector protocols, I think there is a high chance for nodes= to be aware of their neighbors as time goes. As you mentioned, for constra= ined nodes, it might be overhead to keep the neighbor list. But, I don't think it is very resource consuming to find out the neighbors unless consi= dering very dynamic networks.

JP> This is clearly a tradeoff= between protocol overhead to keep track of a list of neighbors (potentiall= y not a negligible amount of data) compared to what it brings to routing. If the motivation is to co= mpute alternate routes, there are other technique and the node degree is no= t sufficient to compute diverse path anyway so this would at best be used a= s a heuristic.

My main concern is whether we need the node degree as a LL= N routing metric and if we do, how we manipulate it. As the document says, = it is questionable whether high node degrees are preferable or not. The decision requires too many factors= need to be considered. Consequently, it'<= /font>s challenging to make use of node degree as a metric.

JP> Right.

So .. I guess that we have a WG consensus not to use it.

Anybody with a different opinion ?

Thanks.

JP.

Thanks.
Mijeom.

On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis <pal@cs.stanford.edu> wrote:=


On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote:


4.6: Is the intention that a node calculates its degree? This is very diffi= cult (some might say impossible under any realistic network scenario). Firs= t, it requires O(n^2) communication. The observation that routing protocols= might want to change decisions based on density makes sense, but by stating it is a metric that implies n= odes calculate it.
=3D=3D=3D>
I think a node can figure out its degree by overhearing. So as time goes, i= t can get the number of neighbors more precisely.<= /p>


That would be true if degree were defined as the number of neighbors a node= can hear. However, it's defined as

  Node degree is the number of neighbors that can receive a messa= ge
  from the node directly.

Unless you assume asymmetric links do not exist, this requires each node to= report the set of nodes from which it hears messages, so those nodes can c= alculate their degree. It also requires a node to maintain state linear in = the number of its neighbors, which is problematic.

Phil

&nbs= p;

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org= /mailman/listinfo/roll


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_A66C224427093F49B30AFFD4A642197F820D0D9296NLCLUEXM03con_-- --===============0135220545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0135220545==-- From roll-bounces@ietf.org Wed Nov 5 12:05:19 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC363A694F; Wed, 5 Nov 2008 12:05:19 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2374F3A694F for ; Wed, 5 Nov 2008 12:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wpIj39Xjjw0 for ; Wed, 5 Nov 2008 12:05:14 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 10B633A6842 for ; Wed, 5 Nov 2008 12:05:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,552,1220227200"; d="scan'208";a="26880135" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Nov 2008 20:04:25 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA5K4PJ9023315; Wed, 5 Nov 2008 15:04:25 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA5K4Pj2012754; Wed, 5 Nov 2008 20:04:25 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Nov 2008 15:04:22 -0500 Received: from 10.61.104.94 ([10.61.104.94]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 5 Nov 2008 20:04:22 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 05 Nov 2008 21:04:21 +0100 From: JP Vasseur To: Richard Kelsey , Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack/gbEFGykroYn2MUKs0NtvPz8weQ== In-Reply-To: <200811051546.mA5FkEoj021461@kelsey-ws.hq.ember.com> Mime-version: 1.0 X-OriginalArrivalTime: 05 Nov 2008 20:04:22.0829 (UTC) FILETIME=[B21C25D0:01C93F81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1617; t=1225915465; x=1226779465; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Richard=20Kelsey=20,=20; bh=U2oXK06YlMVdF8vGrifTHvyALYs/6erGaysSNi8wfQI=; b=oA/wIWi8LPRv09KAAzTGq4GmYLu2JpaWde45PCzkEqFCl0LMvVFd92VtNF blhWdAjEZC6G1O0AmMUjc6GRVD7mwofo+NimX7/WxCkaoYFJZpqvs0YG6b/7 8AVAebIhxD; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Richard, On 11/5/08 4:46 PM, "Richard Kelsey" wrote: > Date: Tue, 04 Nov 2008 16:05:44 -0800 > From: Kris Pister > > I'm still very curious as to where you think that we > should set the "low energy" flag level. Based on the two > scenarios that I presented, I don't see that single-bit > flags have much value. As you pointed out in your > response, the traffic will not be balanced. Either I set > the flag near midpoint, and it doesn't help much, or I > set well below midpoint, and it doesn't help very much. > > It seems to me that the any "low energy" flag would need to > represent an absolute value rather than a percentage. The > fact that two different types of devices have both used 50% > of their capacity doesn't say anything about how many more > messages each is able to route. An example would be a "low > energy" flag indicating that the device's remaining lifetime > was at most 10000 messages/1000 hours, say. Yes we do agree, I think that we reached an agreement on this. > > Also, what matters is the excess capacity beyond the > projected needs of the device itself. Once a device hits a > point where its remaining battery power is only sufficient > for its own needs it will no longer be able to act as a > router, regardless of the actual percentage of remaining > power is available. Sure, the point is indeed to set the flag before running out of battery to move the traffic away from the node. Thanks. JP. > -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 5 14:59:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC7B3A687D; Wed, 5 Nov 2008 14:59:16 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF3B3A6878; Wed, 5 Nov 2008 14:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMt+9lZU3aqy; Wed, 5 Nov 2008 14:59:13 -0800 (PST) Received: from psmtp.com (exprod8ob116.obsmtp.com [64.18.3.31]) by core3.amsl.com (Postfix) with ESMTP id 7F88D3A688A; Wed, 5 Nov 2008 14:59:12 -0800 (PST) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP; Wed, 05 Nov 2008 14:59:11 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008110516593449-1288537 ; Wed, 5 Nov 2008 16:59:34 -0600 In-Reply-To: <4910E358.1030205@eecs.berkeley.edu> MIME-Version: 1.0 To: Kris Pister X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 5 Nov 2008 16:59:02 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/05/2008 04:59:06 PM, Serialize complete at 11/05/2008 04:59:06 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/05/2008 04:59:34 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/05/2008 04:59:38 PM, Serialize complete at 11/05/2008 04:59:38 PM Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1550562736==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============1550562736== Content-Type: multipart/alternative; boundary="=_alternative 007E4105862574F8_=" This is a multipart message in MIME format. --=_alternative 007E4105862574F8_= Content-Type: text/plain; charset="US-ASCII" Why is the IETF trying to establish when the energy flag needs to be set for low battery? This is an application issue. Remaining energy is not a function of time, it's a function of remaining energy. In our current wireless products, we have a comparator that will shut the sensor down at a given voltage level. We have actually calculated the number of joules required per transaction and have back calculated the voltage level at which point we will issue a low-battery alarm. We set the voltage level to alarm about 3 months before the device shuts down, giving the customer 3 months to change the battery. This is for a device that transmits once a minute for about 3 msecs. The battery status is included (1-bit). with every transaction. Two alkaline 'c' cells will last about 10 years, but due to shelf life, we specify 5 year battery life. >From my viewpoint all battery powered wireless devices need to transmit their battery status. For interoperability purposes, this should be dictated. However, this is not a protocol issue, much less a routing issue. This should be something done by the implementers or specified at the alliance level (e.g. IPSO). Jerry Kris Pister Sent by: roll-bounces@ietf.org 11/04/2008 06:06 PM To JP Vasseur cc ROLL WG Subject Re: [Roll] ROLL Routing Metrics - WF feed-back needed Well, we both agree that there will be load imbalance and differential rate of energy consumption, and we both agree that oscillations will be bad. I think that we may have a different picture of the frequency of those oscillations, though. I think that most/all of the systems described in the requirements docs have battery lifetime requirements measured in years. This implies a minimum update rate of, oh, something like monthly. Sending a few tens of bytes of data describing energy and power state on a daily basis is both far more frequent than we need, and unlikely to cause *wasteful* oscillations. If there is some route bouncing with a one day or week period, maybe that's actually optimal. It's certainly not expensive. I'm still very curious as to where you think that we should set the "low energy" flag level. Based on the two scenarios that I presented, I don't see that single-bit flags have much value. As you pointed out in your response, the traffic will not be balanced. Either I set the flag near midpoint, and it doesn't help much, or I set well below midpoint, and it doesn't help very much. I can imagine scenarios in which it works great. Unfortunately, working well 50% of the time doesn't do us much good. We don't have to handle every situation, but we have to at least deal with common problems that come up in real networks. ksjp JP Vasseur wrote: Hi Kris, On 11/4/08 6:28 AM, "Kris Pister" wrote: JP - I'd like to understand more about your flags. If I have a network in which I expect that all motes last for 7 years, where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 years)? At 5% (ideally 3 months)? In the first case, for roughly half of my network lifetime, all of my network will have set the "I'm low on energy" flag, and I will have no useful information with which to make routing decisions. In the second case, I have almost no useful information until it's too late - one year into operation and several of the busiest motes are almost dead, while a mote with a much bigger battery still has almost all of it's charge. So in this case the information shows up too late to be useful. I'm sure that's not the way you see it. What am I missing? See it as a trade-off between frequent accurate updates (=> requiring energy, risk of routing oscillations, ...) and no information at all. If you make the assumption of uniform energy consumption, then flags are always useless (so does more up to date data). On the other hand if you see the use of such flags as safeguard mechanisms, this could be useful to start rerouting the traffic around nodes running out of battery. Suppose that the traffic is not equally balanced in the network, you may end up with nodes consuming battery at a much higher rates than others, in which case the flags may be useful, with no risk of oscillation. Thoughts ? Cheers, JP. ksjp JP Vasseur wrote: Hi Miguel, On 10/31/08 12:24 PM, "Miguel Sanchez" wrote: Hi JP, On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur wrote: Hi Kris, On 10/30/08 5:33 PM, "Kris Pister" wrote: I agree with Miguel that we need a standard way of energy reporting, and I agree with JP that it's hard to do. Part of the challenge is that energy sources and storage vary so much. We have: * line power - great if you can get it! * battery storage - this is time varying. The available energy in a battery is a strong function of the temperature and the usage profile. So a battery powered mote may correctly calculate five years of lifetime in summer, and then that winter under the exact same load conditions it may correctly calculate a lifetime of ten years. The same mote with the same battery may have better performance in summer at higher loads. JP> and usage profile may also change. * capacitive storage * energy scavenging - this is time varying, and tough to bound (usefully JP> this is why I'm questioning the usefulness of knowing the remaining energy expressed in Joules or other metrics. Knowing this value will not tell you anything as to whether you should or should not use that node when computing the path. Another metric may be the remaining estimated lifetime I disagree. At least if remaining energy is infinitum (mains powered) tells you something. OTOH, if limited, depending on other properties of the nodes (like where it gets its energy from) it is also useful for making routing decisions too. OK let's try to step back. I'm proposing a flag-based mechanism to avoid the use of a node should this node run out of energy. The decision to set the flag is made by the node (no specified) according to many parameters (estimated like time, ... Etc). Some nodes having more power may make use of complex models. If you advertise your remaining power in Joules, how would you expect the nodes to change their routing decisions since they have no idea of whether you are running low in energy (it highly depends on what the node does, the external conditions, ... Etc) ? Thanks. JP. but still, is the node capable (without consuming too much energy) of gathering historical data etc ... to provide an accurate value hoping that other criterion such as usage profile or temperature as you pointed out will not change ? All of this makes energy/power/lifetime reporting painful, yet I can not picture a successful routing protocol that doesn't somehow take these factors into account. Kind regards, Miguel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 007E4105862574F8_= Content-Type: text/html; charset="US-ASCII"
Why is the IETF trying to establish when the energy flag needs to be set for low battery?  This is an application issue.  

Remaining energy is not a function of time, it's a function of remaining energy.  In our current wireless products, we have a comparator that will shut the sensor down at a given voltage level.  We have actually calculated the number of joules required per transaction and have back calculated the voltage level at which point we will issue a low-battery alarm.  We set the voltage level to alarm about 3 months before the device shuts down, giving the customer 3 months to change the battery.  This is for a device that transmits once a minute for about 3 msecs.  The battery status is included (1-bit). with every transaction.  Two alkaline  'c' cells will last about 10 years, but due to shelf life, we specify 5 year battery life.

From my viewpoint all battery powered wireless devices need to transmit their battery status.  For interoperability purposes, this should be dictated.  However, this is not a protocol issue, much less a routing issue.  This should be something done by the implementers or specified at the alliance level (e.g. IPSO).

Jerry





Kris Pister <pister@eecs.berkeley.edu>
Sent by: roll-bounces@ietf.org

11/04/2008 06:06 PM

To
JP Vasseur <jvasseur@cisco.com>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] ROLL Routing Metrics - WF feed-back needed





Well, we both agree that there will be load imbalance and differential rate of energy consumption,
and we both agree that oscillations will be bad.  I think that we may have a different picture of the
frequency of those oscillations, though.  I think that most/all of the systems described in the
requirements docs have battery lifetime requirements measured in years.  This implies a minimum
update rate of, oh, something like monthly.  Sending a few tens of bytes of data describing
energy and power state on a daily basis is both far more frequent than we need, and unlikely
to cause *wasteful* oscillations.  If there is some route bouncing with a one day or week period, maybe
that's actually optimal.  It's certainly not expensive.

I'm still very curious as to where you think that we should set the "low energy" flag level.  Based on the two scenarios that I presented, I don't see that single-bit flags have much value.  As you pointed out in your response, the traffic will not be balanced.  Either I set the flag near midpoint, and it doesn't help much, or I set well below midpoint, and it doesn't help very much.

I can imagine scenarios in which it works great.  Unfortunately, working well 50% of the time doesn't do us much good.  We don't have to handle every situation, but we have to at least deal with common problems that come up in real networks.

ksjp

JP Vasseur wrote:
Hi Kris,


On 11/4/08 6:28 AM, "Kris Pister" <pister@eecs.berkeley.edu> wrote:

 
JP - I'd like to understand more about your flags.
If I have a network in which I expect that all motes last for 7 years,
where do I set the "I'm low on energy" flag?  At 50% (ideally 3.5
years)?  At 5% (ideally 3 months)?
In the first case, for roughly half of my network lifetime, all of my
network will have set the "I'm low on energy" flag, and I will have no
useful information with which to make routing decisions.
In the second case, I have almost no useful information until it's too
late - one year into operation and several of the busiest motes are
almost dead, while a mote with a much bigger battery still has almost
all of it's charge.  So in this case the information shows up too late
to be useful.
I'm sure that's not the way you see it.  What am I missing?

   

See it as a trade-off between frequent accurate updates (=> requiring
energy, risk of routing oscillations, ...) and no information at all. If you
make the assumption of uniform energy consumption, then flags are always
useless (so does more up to date data). On the other hand if you see the use
of such flags as safeguard mechanisms, this could be useful to start
rerouting the traffic around nodes running out of battery. Suppose that the
traffic is not equally balanced in the network, you may end up with nodes
consuming battery at a much higher rates than others, in which case the
flags may be useful, with no risk of oscillation.

Thoughts ?

Cheers,

JP.

 
ksjp

JP Vasseur wrote:
   
Hi Miguel,


On 10/31/08 12:24 PM, "Miguel Sanchez" <misan@disca.upv.es> wrote:

 
     
Hi JP,



On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur <jvasseur@cisco.com> wrote:
   
       
Hi Kris,


On 10/30/08 5:33 PM, "Kris Pister" <pister@eecs.berkeley.edu> wrote:

I agree with Miguel that we need a standard way of energy reporting, and I
agree with JP that it's hard to do.
Part of the challenge is that energy sources and storage vary so much. We
have:
* line power - great if you can get it!
* battery storage
     - this is time varying.  The available energy in a battery is a
strong
function of the temperature and the usage profile.  So a battery powered
mote may correctly calculate five years of lifetime in summer, and then
that
winter under the exact same load conditions it may correctly calculate a
lifetime of ten years.  The same mote with the same battery may have better
performance in summer at higher loads.

JP> and usage profile may also change.

* capacitive storage
* energy scavenging
     - this is time varying, and tough to bound (usefully

JP> this is why I'm questioning the usefulness of knowing the remaining
energy expressed in Joules or other metrics. Knowing this value will not
tell you anything as to whether you should or should not use that node when
computing the path. Another metric may be the remaining estimated lifetime
     
         
I disagree.

At least if remaining energy is infinitum (mains powered) tells you
something.

OTOH, if limited, depending on other properties of the nodes (like
where it gets its energy from) it is also useful for making routing
decisions too.
   
       
OK let's try to step back. I'm proposing a flag-based mechanism to avoid the
use of a node should this node run out of energy. The decision to set the
flag is made by the node (no specified) according to many parameters
(estimated like time, ... Etc). Some nodes having more power may make use of
complex models.

If you advertise your remaining power in Joules, how would you expect the
nodes to change their routing decisions since they have no idea of whether
you are running low in energy (it highly depends on what the node does, the
external conditions, ... Etc) ?

Thanks.

JP.

 
     
but still, is the node capable (without consuming too much energy) of
gathering historical data etc ... to provide an accurate value hoping that
other criterion such as usage profile or temperature as you pointed out
will
not change ?

All of this makes energy/power/lifetime reporting painful, yet I can not
picture a successful routing protocol that doesn't somehow take these
factors into account.

     
         
Kind regards,

Miguel
   
       
 
     

 _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 007E4105862574F8_=-- --===============1550562736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1550562736==-- From roll-bounces@ietf.org Wed Nov 5 20:08:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CEA3A6824; Wed, 5 Nov 2008 20:08:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30A73A63CB for ; Wed, 5 Nov 2008 20:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atZXtkGvfMnU for ; Wed, 5 Nov 2008 20:08:06 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id BA5823A6824 for ; Wed, 5 Nov 2008 20:08:06 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mA647rSN014266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Nov 2008 20:07:58 -0800 (PST) Message-ID: <49126E8D.5030306@eecs.berkeley.edu> Date: Wed, 05 Nov 2008 20:11:57 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Jerry - I'm not trying to get the IETF decide the threshold for any flags. My point is that a single bit flag is virtually useless for making intelligent routing decisions, regardless of what threshold value you choose for it. You say that remaining energy is not a function of time, and yet the units you use to describe where you set the threshold are "months" :) Somehow we have to make the same kind of translations between Joules and months, and for networks where the routers are battery powered, this IS a routing issue. Here's why: ignoring energy in routing decisions, protocol X creates networks that have a distribution of lifetimes varying, for example, from three to fifteen years. Protocol Y, using energy in its routing decisions, builds networks that have the same mean lifetime, but a distribution that is much tighter - from 9 to 12 years. Which one would you rather buy? One where you start replacing batteries after 3 years, or one were you replace them all at 9 years? ksjp Jerald.P.Martocci@jci.com wrote: > > Why is the IETF trying to establish when the energy flag needs to be > set for low battery? This is an application issue. > > Remaining energy is not a function of time, it's a function of > remaining energy. In our current wireless products, we have a > comparator that will shut the sensor down at a given voltage level. > We have actually calculated the number of joules required per > transaction and have back calculated the voltage level at which point > we will issue a low-battery alarm. We set the voltage level to alarm > about 3 months before the device shuts down, giving the customer 3 > months to change the battery. This is for a device that transmits > once a minute for about 3 msecs. The battery status is included > (1-bit). with every transaction. Two alkaline 'c' cells will last > about 10 years, but due to shelf life, we specify 5 year battery life. > > From my viewpoint all battery powered wireless devices need to > transmit their battery status. For interoperability purposes, this > should be dictated. However, this is not a protocol issue, much less > a routing issue. This should be something done by the implementers or > specified at the alliance level (e.g. IPSO). > > Jerry > > > > > > *Kris Pister * > Sent by: roll-bounces@ietf.org > > 11/04/2008 06:06 PM > > > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > > > > > > > Well, we both agree that there will be load imbalance and differential > rate of energy consumption, > and we both agree that oscillations will be bad. I think that we may > have a different picture of the > frequency of those oscillations, though. I think that most/all of the > systems described in the > requirements docs have battery lifetime requirements measured in > years. This implies a minimum > update rate of, oh, something like monthly. Sending a few tens of > bytes of data describing > energy and power state on a daily basis is both far more frequent than > we need, and unlikely > to cause *wasteful* oscillations. If there is some route bouncing > with a one day or week period, maybe > that's actually optimal. It's certainly not expensive. > > I'm still very curious as to where you think that we should set the > "low energy" flag level. Based on the two scenarios that I presented, > I don't see that single-bit flags have much value. As you pointed out > in your response, the traffic will not be balanced. Either I set the > flag near midpoint, and it doesn't help much, or I set well below > midpoint, and it doesn't help very much. > > I can imagine scenarios in which it works great. Unfortunately, > working well 50% of the time doesn't do us much good. We don't have > to handle every situation, but we have to at least deal with common > problems that come up in real networks. > > ksjp > > JP Vasseur wrote: > Hi Kris, > > > On 11/4/08 6:28 AM, "Kris Pister" __ > wrote: > > > JP - I'd like to understand more about your flags. > If I have a network in which I expect that all motes last for 7 years, > where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 > years)? At 5% (ideally 3 months)? > In the first case, for roughly half of my network lifetime, all of my > network will have set the "I'm low on energy" flag, and I will have no > useful information with which to make routing decisions. > In the second case, I have almost no useful information until it's too > late - one year into operation and several of the busiest motes are > almost dead, while a mote with a much bigger battery still has almost > all of it's charge. So in this case the information shows up too late > to be useful. > I'm sure that's not the way you see it. What am I missing? > > > > See it as a trade-off between frequent accurate updates (=> requiring > energy, risk of routing oscillations, ...) and no information at all. > If you > make the assumption of uniform energy consumption, then flags are always > useless (so does more up to date data). On the other hand if you see > the use > of such flags as safeguard mechanisms, this could be useful to start > rerouting the traffic around nodes running out of battery. Suppose > that the > traffic is not equally balanced in the network, you may end up with nodes > consuming battery at a much higher rates than others, in which case the > flags may be useful, with no risk of oscillation. > > Thoughts ? > > Cheers, > > JP. > > > ksjp > > JP Vasseur wrote: > > Hi Miguel, > > > On 10/31/08 12:24 PM, "Miguel Sanchez" __ > wrote: > > > > Hi JP, > > > > On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur __ > wrote: > > > Hi Kris, > > > On 10/30/08 5:33 PM, "Kris Pister" __ > wrote: > > I agree with Miguel that we need a standard way of energy reporting, and I > agree with JP that it's hard to do. > Part of the challenge is that energy sources and storage vary so much. We > have: > * line power - great if you can get it! > * battery storage > - this is time varying. The available energy in a battery is a > strong > function of the temperature and the usage profile. So a battery powered > mote may correctly calculate five years of lifetime in summer, and then > that > winter under the exact same load conditions it may correctly calculate a > lifetime of ten years. The same mote with the same battery may have > better > performance in summer at higher loads. > > JP> and usage profile may also change. > > * capacitive storage > * energy scavenging > - this is time varying, and tough to bound (usefully > > JP> this is why I'm questioning the usefulness of knowing the remaining > energy expressed in Joules or other metrics. Knowing this value will not > tell you anything as to whether you should or should not use that node > when > computing the path. Another metric may be the remaining estimated lifetime > > > I disagree. > > At least if remaining energy is infinitum (mains powered) tells you > something. > > OTOH, if limited, depending on other properties of the nodes (like > where it gets its energy from) it is also useful for making routing > decisions too. > > > OK let's try to step back. I'm proposing a flag-based mechanism to > avoid the > use of a node should this node run out of energy. The decision to set the > flag is made by the node (no specified) according to many parameters > (estimated like time, ... Etc). Some nodes having more power may make > use of > complex models. > > If you advertise your remaining power in Joules, how would you expect the > nodes to change their routing decisions since they have no idea of whether > you are running low in energy (it highly depends on what the node > does, the > external conditions, ... Etc) ? > > Thanks. > > JP. > > > > but still, is the node capable (without consuming too much energy) of > gathering historical data etc ... to provide an accurate value hoping that > other criterion such as usage profile or temperature as you pointed out > will > not change ? > > All of this makes energy/power/lifetime reporting painful, yet I can not > picture a successful routing protocol that doesn't somehow take these > factors into account. > > > > Kind regards, > > Miguel > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 6 12:06:15 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68383A68FA; Thu, 6 Nov 2008 12:06:15 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B883A68FA for ; Thu, 6 Nov 2008 12:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1wl9On4xpzS for ; Thu, 6 Nov 2008 12:06:12 -0800 (PST) Received: from psmtp.com (exprod8ob116.obsmtp.com [64.18.3.31]) by core3.amsl.com (Postfix) with ESMTP id E06BE3A6813 for ; Thu, 6 Nov 2008 12:06:08 -0800 (PST) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP; Thu, 06 Nov 2008 12:06:07 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2008110614043662-1410668 ; Thu, 6 Nov 2008 14:04:36 -0600 In-Reply-To: <49126E8D.5030306@eecs.berkeley.edu> MIME-Version: 1.0 To: Kris Pister X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 6 Nov 2008 14:04:12 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 11/06/2008 02:04:19 PM, Serialize complete at 11/06/2008 02:04:19 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/06/2008 02:04:36 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 11/06/2008 02:06:23 PM, Serialize complete at 11/06/2008 02:06:23 PM Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0344037890==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multipart message in MIME format. --===============0344037890== Content-Type: multipart/alternative; boundary="=_alternative 006E3FAA862574F9_=" This is a multipart message in MIME format. --=_alternative 006E3FAA862574F9_= Content-Type: text/plain; charset="US-ASCII" Kris, I'm getting your point, to a point... First off, in the Commercial Building market, all routering devices will be lines powered and hence the routing protocol need not concern itself with power starved routers. You must be vying for some sort of synchronous network where the routers power up on a very short duty cycle. Our radios typically require 10000x more energy (~27ma) when powered up and transmitting or receiving than asleep (2uA). You would blow out the joules of any reasonably sized battery quite quickly if the receiver needed to be on for extended periods on the off-chance that a message needed to be routered through it. As for the routing protocol needing a priori knowledge of the battery status of a device to determine selected paths, I still don't see this as a network routing parameter. The node that becomes energy starved simply needs to stop forwarding routed messages. The transport will quickly notice that messages are not reaching their destination and advertise for a new path to which our energy starved device won't respond. A more graceful approach would be for the energy starved node to simply tell the source node that it is temporarily out of the routering business. This functionality needs to be in place anyway since even in normal operation, an existing path might get blocked. By advertising remaining energy throughout the network and making systemic routing choices based on available energy seems like a nice thing to do and would tend to balance the total available energy across the mesh. However, the network also must understand the application running on the node to make the choice. For example, let's say I have a battery powered repeater installed in a sparse portion of the mesh. This device has no other meaning in life but to route messages. Rerouting around this device saves the energy on a device that has no reason to save energy. Also, remember this repeater was strategically placed to 'fill-in' the mesh. By taking it out of the mesh routes, all the other nodes will need to use up more of their available energy to make up for this missing node. Conversely, (kind of!!!) let's say I have a sensor that needs to report status temporally. Even if I stop routing, I still need to awaken to do my own task on a periodic basis. In many cases I can synchronize my application with the duty cycle of the network. Now I can continue to perform both jobs without reducing energy any more than I would performing my one required job. My point being that it is important to understand the application requirements as well as battery status to make judicious routing decisions. Why not let each device decide no its own if it can save power by taking itself out of the routing paths. The mesh would then just re-form as needed around the devices. Jerry Kris Pister 11/05/2008 10:08 PM To Jerald.P.Martocci@jci.com cc ROLL WG Subject Re: [Roll] ROLL Routing Metrics - WF feed-back needed Jerry - I'm not trying to get the IETF decide the threshold for any flags. My point is that a single bit flag is virtually useless for making intelligent routing decisions, regardless of what threshold value you choose for it. You say that remaining energy is not a function of time, and yet the units you use to describe where you set the threshold are "months" :) Somehow we have to make the same kind of translations between Joules and months, and for networks where the routers are battery powered, this IS a routing issue. Here's why: ignoring energy in routing decisions, protocol X creates networks that have a distribution of lifetimes varying, for example, from three to fifteen years. Protocol Y, using energy in its routing decisions, builds networks that have the same mean lifetime, but a distribution that is much tighter - from 9 to 12 years. Which one would you rather buy? One where you start replacing batteries after 3 years, or one were you replace them all at 9 years? ksjp Jerald.P.Martocci@jci.com wrote: > > Why is the IETF trying to establish when the energy flag needs to be > set for low battery? This is an application issue. > > Remaining energy is not a function of time, it's a function of > remaining energy. In our current wireless products, we have a > comparator that will shut the sensor down at a given voltage level. > We have actually calculated the number of joules required per > transaction and have back calculated the voltage level at which point > we will issue a low-battery alarm. We set the voltage level to alarm > about 3 months before the device shuts down, giving the customer 3 > months to change the battery. This is for a device that transmits > once a minute for about 3 msecs. The battery status is included > (1-bit). with every transaction. Two alkaline 'c' cells will last > about 10 years, but due to shelf life, we specify 5 year battery life. > > From my viewpoint all battery powered wireless devices need to > transmit their battery status. For interoperability purposes, this > should be dictated. However, this is not a protocol issue, much less > a routing issue. This should be something done by the implementers or > specified at the alliance level (e.g. IPSO). > > Jerry > > > > > > *Kris Pister * > Sent by: roll-bounces@ietf.org > > 11/04/2008 06:06 PM > > > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > > > > > > > Well, we both agree that there will be load imbalance and differential > rate of energy consumption, > and we both agree that oscillations will be bad. I think that we may > have a different picture of the > frequency of those oscillations, though. I think that most/all of the > systems described in the > requirements docs have battery lifetime requirements measured in > years. This implies a minimum > update rate of, oh, something like monthly. Sending a few tens of > bytes of data describing > energy and power state on a daily basis is both far more frequent than > we need, and unlikely > to cause *wasteful* oscillations. If there is some route bouncing > with a one day or week period, maybe > that's actually optimal. It's certainly not expensive. > > I'm still very curious as to where you think that we should set the > "low energy" flag level. Based on the two scenarios that I presented, > I don't see that single-bit flags have much value. As you pointed out > in your response, the traffic will not be balanced. Either I set the > flag near midpoint, and it doesn't help much, or I set well below > midpoint, and it doesn't help very much. > > I can imagine scenarios in which it works great. Unfortunately, > working well 50% of the time doesn't do us much good. We don't have > to handle every situation, but we have to at least deal with common > problems that come up in real networks. > > ksjp > > JP Vasseur wrote: > Hi Kris, > > > On 11/4/08 6:28 AM, "Kris Pister" __ > wrote: > > > JP - I'd like to understand more about your flags. > If I have a network in which I expect that all motes last for 7 years, > where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 > years)? At 5% (ideally 3 months)? > In the first case, for roughly half of my network lifetime, all of my > network will have set the "I'm low on energy" flag, and I will have no > useful information with which to make routing decisions. > In the second case, I have almost no useful information until it's too > late - one year into operation and several of the busiest motes are > almost dead, while a mote with a much bigger battery still has almost > all of it's charge. So in this case the information shows up too late > to be useful. > I'm sure that's not the way you see it. What am I missing? > > > > See it as a trade-off between frequent accurate updates (=> requiring > energy, risk of routing oscillations, ...) and no information at all. > If you > make the assumption of uniform energy consumption, then flags are always > useless (so does more up to date data). On the other hand if you see > the use > of such flags as safeguard mechanisms, this could be useful to start > rerouting the traffic around nodes running out of battery. Suppose > that the > traffic is not equally balanced in the network, you may end up with nodes > consuming battery at a much higher rates than others, in which case the > flags may be useful, with no risk of oscillation. > > Thoughts ? > > Cheers, > > JP. > > > ksjp > > JP Vasseur wrote: > > Hi Miguel, > > > On 10/31/08 12:24 PM, "Miguel Sanchez" __ > wrote: > > > > Hi JP, > > > > On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur __ > wrote: > > > Hi Kris, > > > On 10/30/08 5:33 PM, "Kris Pister" __ > wrote: > > I agree with Miguel that we need a standard way of energy reporting, and I > agree with JP that it's hard to do. > Part of the challenge is that energy sources and storage vary so much. We > have: > * line power - great if you can get it! > * battery storage > - this is time varying. The available energy in a battery is a > strong > function of the temperature and the usage profile. So a battery powered > mote may correctly calculate five years of lifetime in summer, and then > that > winter under the exact same load conditions it may correctly calculate a > lifetime of ten years. The same mote with the same battery may have > better > performance in summer at higher loads. > > JP> and usage profile may also change. > > * capacitive storage > * energy scavenging > - this is time varying, and tough to bound (usefully > > JP> this is why I'm questioning the usefulness of knowing the remaining > energy expressed in Joules or other metrics. Knowing this value will not > tell you anything as to whether you should or should not use that node > when > computing the path. Another metric may be the remaining estimated lifetime > > > I disagree. > > At least if remaining energy is infinitum (mains powered) tells you > something. > > OTOH, if limited, depending on other properties of the nodes (like > where it gets its energy from) it is also useful for making routing > decisions too. > > > OK let's try to step back. I'm proposing a flag-based mechanism to > avoid the > use of a node should this node run out of energy. The decision to set the > flag is made by the node (no specified) according to many parameters > (estimated like time, ... Etc). Some nodes having more power may make > use of > complex models. > > If you advertise your remaining power in Joules, how would you expect the > nodes to change their routing decisions since they have no idea of whether > you are running low in energy (it highly depends on what the node > does, the > external conditions, ... Etc) ? > > Thanks. > > JP. > > > > but still, is the node capable (without consuming too much energy) of > gathering historical data etc ... to provide an accurate value hoping that > other criterion such as usage profile or temperature as you pointed out > will > not change ? > > All of this makes energy/power/lifetime reporting painful, yet I can not > picture a successful routing protocol that doesn't somehow take these > factors into account. > > > > Kind regards, > > Miguel > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=_alternative 006E3FAA862574F9_= Content-Type: text/html; charset="US-ASCII"
Kris,

I'm getting your point, to a point...

First off, in the Commercial Building market, all routering devices will be lines powered and hence the routing protocol need not concern itself with power starved routers.  You must be vying for some sort of synchronous network where the routers power up on a very short duty cycle.  Our radios typically require 10000x more energy (~27ma) when powered up and transmitting or receiving  than asleep (2uA).  You would blow out the joules of any reasonably sized battery quite quickly if the receiver needed to be on for extended periods on the off-chance that a message needed to be routered through it.  

As for the routing protocol needing a priori knowledge of the battery status of a device to determine selected paths, I still don't see this as a network routing parameter.  The node that becomes energy starved simply needs to stop forwarding routed messages.   The transport will quickly notice that messages are not reaching their destination and advertise for a new path to which our energy starved device won't respond.  A more graceful approach would be for the energy starved node to simply tell the source node that it is temporarily out of the routering business.  This functionality needs to be in place anyway since even in normal operation, an existing path might get blocked.

By advertising remaining energy throughout the network and making systemic routing choices based on available energy seems like a nice thing to do and would tend to balance the total available energy across the mesh.  However, the network also must understand the application running on the node to make the choice.  For example, let's say I have a battery powered repeater installed in a sparse portion of the mesh.  This device has no other meaning in life but to route messages.  Rerouting around this device saves the energy on a device that has no reason to save energy.  Also, remember this repeater was strategically placed to 'fill-in' the mesh.  By taking it out of the mesh routes, all the other nodes will need to use up more of their available energy to make up for this missing node.

Conversely, (kind of!!!) let's say I have a sensor that needs to report status temporally.  Even if I stop routing, I still need to awaken to do my own task on a periodic basis.  In many cases I can synchronize my application with the duty cycle of the network.  Now I can continue to perform both jobs without reducing energy any more than I would performing my one required job.

My point being that it is important to understand the application requirements as well as battery status to make judicious routing decisions.  Why not let each device decide no its own if it can save power by taking itself out of the routing paths.  The mesh would then just re-form as needed around the devices.

Jerry




Kris Pister <pister@eecs.berkeley.edu>

11/05/2008 10:08 PM

To
Jerald.P.Martocci@jci.com
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] ROLL Routing Metrics - WF feed-back needed





Jerry - I'm not trying to get the IETF decide the threshold for any
flags.  My point is that a single bit flag is virtually useless for
making intelligent routing decisions, regardless of what threshold value
you choose for it.

You say that remaining energy is not a function of time, and yet the
units you use to describe where you set the threshold are "months" :)  
Somehow we have to make the same kind of translations between Joules and
months, and for networks where the routers are battery powered, this IS
a routing issue.

Here's why: ignoring energy in routing decisions, protocol X creates
networks that have a distribution of lifetimes varying, for example,
from three to fifteen years.  Protocol Y, using energy in its routing
decisions, builds networks that have the same mean lifetime, but a
distribution that is much tighter - from 9 to 12 years.  Which one would
you rather buy?  One where you start replacing batteries after 3 years,
or one were you replace them all at 9 years?

ksjp

Jerald.P.Martocci@jci.com wrote:
>
> Why is the IETF trying to establish when the energy flag needs to be
> set for low battery?  This is an application issue.  
>
> Remaining energy is not a function of time, it's a function of
> remaining energy.  In our current wireless products, we have a
> comparator that will shut the sensor down at a given voltage level.
>  We have actually calculated the number of joules required per
> transaction and have back calculated the voltage level at which point
> we will issue a low-battery alarm.  We set the voltage level to alarm
> about 3 months before the device shuts down, giving the customer 3
> months to change the battery.  This is for a device that transmits
> once a minute for about 3 msecs.  The battery status is included
> (1-bit). with every transaction.  Two alkaline  'c' cells will last
> about 10 years, but due to shelf life, we specify 5 year battery life.
>
> From my viewpoint all battery powered wireless devices need to
> transmit their battery status.  For interoperability purposes, this
> should be dictated.  However, this is not a protocol issue, much less
> a routing issue.  This should be something done by the implementers or
> specified at the alliance level (e.g. IPSO).
>
> Jerry
>
>
>
>
>
> *Kris Pister <pister@eecs.berkeley.edu>*
> Sent by: roll-bounces@ietf.org
>
> 11/04/2008 06:06 PM
>
>                  
> To
>                  JP Vasseur <jvasseur@cisco.com>
> cc
>                  ROLL WG <roll@ietf.org>
> Subject
>                  Re: [Roll] ROLL Routing Metrics - WF feed-back needed
>
>
>
>                  
>
>
>
>
>
> Well, we both agree that there will be load imbalance and differential
> rate of energy consumption,
> and we both agree that oscillations will be bad.  I think that we may
> have a different picture of the
> frequency of those oscillations, though.  I think that most/all of the
> systems described in the
> requirements docs have battery lifetime requirements measured in
> years.  This implies a minimum
> update rate of, oh, something like monthly.  Sending a few tens of
> bytes of data describing
> energy and power state on a daily basis is both far more frequent than
> we need, and unlikely
> to cause *wasteful* oscillations.  If there is some route bouncing
> with a one day or week period, maybe
> that's actually optimal.  It's certainly not expensive.
>
> I'm still very curious as to where you think that we should set the
> "low energy" flag level.  Based on the two scenarios that I presented,
> I don't see that single-bit flags have much value.  As you pointed out
> in your response, the traffic will not be balanced.  Either I set the
> flag near midpoint, and it doesn't help much, or I set well below
> midpoint, and it doesn't help very much.
>
> I can imagine scenarios in which it works great.  Unfortunately,
> working well 50% of the time doesn't do us much good.  We don't have
> to handle every situation, but we have to at least deal with common
> problems that come up in real networks.
>
> ksjp
>
> JP Vasseur wrote:
> Hi Kris,
>
>
> On 11/4/08 6:28 AM, "Kris Pister" _<pister@eecs.berkeley.edu>_
> <mailto:pister@eecs.berkeley.edu> wrote:
>
>  
> JP - I'd like to understand more about your flags.
> If I have a network in which I expect that all motes last for 7 years,
> where do I set the "I'm low on energy" flag?  At 50% (ideally 3.5
> years)?  At 5% (ideally 3 months)?
> In the first case, for roughly half of my network lifetime, all of my
> network will have set the "I'm low on energy" flag, and I will have no
> useful information with which to make routing decisions.
> In the second case, I have almost no useful information until it's too
> late - one year into operation and several of the busiest motes are
> almost dead, while a mote with a much bigger battery still has almost
> all of it's charge.  So in this case the information shows up too late
> to be useful.
> I'm sure that's not the way you see it.  What am I missing?
>
>    
>
> See it as a trade-off between frequent accurate updates (=> requiring
> energy, risk of routing oscillations, ...) and no information at all.
> If you
> make the assumption of uniform energy consumption, then flags are always
> useless (so does more up to date data). On the other hand if you see
> the use
> of such flags as safeguard mechanisms, this could be useful to start
> rerouting the traffic around nodes running out of battery. Suppose
> that the
> traffic is not equally balanced in the network, you may end up with nodes
> consuming battery at a much higher rates than others, in which case the
> flags may be useful, with no risk of oscillation.
>
> Thoughts ?
>
> Cheers,
>
> JP.
>
>  
> ksjp
>
> JP Vasseur wrote:
>    
> Hi Miguel,
>
>
> On 10/31/08 12:24 PM, "Miguel Sanchez" _<misan@disca.upv.es>_
> <mailto:misan@disca.upv.es> wrote:
>
>  
>      
> Hi JP,
>
>
>
> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur _<jvasseur@cisco.com>_
> <mailto:jvasseur@cisco.com> wrote:
>    
>        
> Hi Kris,
>
>
> On 10/30/08 5:33 PM, "Kris Pister" _<pister@eecs.berkeley.edu>_
> <mailto:pister@eecs.berkeley.edu> wrote:
>
> I agree with Miguel that we need a standard way of energy reporting, and I
> agree with JP that it's hard to do.
> Part of the challenge is that energy sources and storage vary so much. We
> have:
> * line power - great if you can get it!
> * battery storage
>      - this is time varying.  The available energy in a battery is a
> strong
> function of the temperature and the usage profile.  So a battery powered
> mote may correctly calculate five years of lifetime in summer, and then
> that
> winter under the exact same load conditions it may correctly calculate a
> lifetime of ten years.  The same mote with the same battery may have
> better
> performance in summer at higher loads.
>
> JP> and usage profile may also change.
>
> * capacitive storage
> * energy scavenging
>      - this is time varying, and tough to bound (usefully
>
> JP> this is why I'm questioning the usefulness of knowing the remaining
> energy expressed in Joules or other metrics. Knowing this value will not
> tell you anything as to whether you should or should not use that node
> when
> computing the path. Another metric may be the remaining estimated lifetime
>      
>          
> I disagree.
>
> At least if remaining energy is infinitum (mains powered) tells you
> something.
>
> OTOH, if limited, depending on other properties of the nodes (like
> where it gets its energy from) it is also useful for making routing
> decisions too.
>    
>        
> OK let's try to step back. I'm proposing a flag-based mechanism to
> avoid the
> use of a node should this node run out of energy. The decision to set the
> flag is made by the node (no specified) according to many parameters
> (estimated like time, ... Etc). Some nodes having more power may make
> use of
> complex models.
>
> If you advertise your remaining power in Joules, how would you expect the
> nodes to change their routing decisions since they have no idea of whether
> you are running low in energy (it highly depends on what the node
> does, the
> external conditions, ... Etc) ?
>
> Thanks.
>
> JP.
>
>  
>      
> but still, is the node capable (without consuming too much energy) of
> gathering historical data etc ... to provide an accurate value hoping that
> other criterion such as usage profile or temperature as you pointed out
> will
> not change ?
>
> All of this makes energy/power/lifetime reporting painful, yet I can not
> picture a successful routing protocol that doesn't somehow take these
> factors into account.
>
>      
>          
> Kind regards,
>
> Miguel
>    
>        
>  
>      
>
>  _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
--=_alternative 006E3FAA862574F9_=-- --===============0344037890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0344037890==-- From roll-bounces@ietf.org Fri Nov 7 05:37:56 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE25F3A68A6; Fri, 7 Nov 2008 05:37:56 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C413A68A6 for ; Fri, 7 Nov 2008 05:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.416 X-Spam-Level: X-Spam-Status: No, score=-5.416 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VeKyWOJxmy9 for ; Fri, 7 Nov 2008 05:37:55 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EF5EE3A680E for ; Fri, 7 Nov 2008 05:37:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,564,1220227200"; d="scan'208,217";a="27047285" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2008 13:37:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA7Dbcij000402; Fri, 7 Nov 2008 08:37:38 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA7Dbc8w004668; Fri, 7 Nov 2008 13:37:38 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Nov 2008 08:37:38 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Nov 2008 13:37:37 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Fri, 07 Nov 2008 14:37:36 +0100 From: JP Vasseur To: Message-ID: Thread-Topic: WG Last Call: draft-ietf-roll-indus-routing-reqs-02 Thread-Index: AclA3f6WRpg0DZH4r0CKa246K7fFPA== Mime-version: 1.0 X-OriginalArrivalTime: 07 Nov 2008 13:37:38.0277 (UTC) FILETIME=[FFF20150:01C940DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1018; t=1226065058; x=1226929058; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20WG=20Last=20Call=3A=20draft-ietf-roll-indus-rou ting-reqs-02 |Sender:=20 |To:=20; bh=+jYoF/fdq1L570U9WmRWx9vjhyWQ0tVZSj3eR7Et2rU=; b=vHQJEX24bnVzO2/ieWfPD22sS16Ia1SpN5EErcIdmpOD2dpQKrBTsSpMEr UamuhmUKIA2nwOWtzTc5M6r7xpql7xzcfJuGbulSF2/mjL338VDtC2Ol9xpH ZI2O+/sdbG; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sicco.dwars@shell.com, tom.phinney@cox.net Subject: [Roll] WG Last Call: draft-ietf-roll-indus-routing-reqs-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0028700895==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0028700895== Content-type: multipart/alternative; boundary="B_3308913457_4597432" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3308913457_4597432 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, This starts a 3-week Working Group Last Call on draft-ietf-roll-indus-routing-reqs-02 ending on Nov 28 at noon ET. Thanks to send your comments to the authors and copy the list. Thanks. JP. --B_3308913457_4597432 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable WG Last Call: draft-ietf-roll-indus-routing-reqs-02 Dear WG,

This starts a 3-week Working Group Last Call on draft-ietf-roll-indus-routi= ng-reqs-02 ending on Nov 28 at noon ET. Thanks to send your comments to the = authors and copy the list.

Thanks.

JP. --B_3308913457_4597432-- --===============0028700895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0028700895==-- From roll-bounces@ietf.org Fri Nov 7 05:53:36 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5683A3A69B0; Fri, 7 Nov 2008 05:53:36 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04693A69B0 for ; Fri, 7 Nov 2008 05:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KggqvGTofxY8 for ; Fri, 7 Nov 2008 05:53:33 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 05F7B3A6968 for ; Fri, 7 Nov 2008 05:53:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,564,1220227200"; d="scan'208";a="24975676" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2008 13:52:54 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA7Dqs9p020795 for ; Fri, 7 Nov 2008 14:52:54 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA7Dqsxk012798 for ; Fri, 7 Nov 2008 13:52:54 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Nov 2008 14:52:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Nov 2008 14:52:48 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0683DF47@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclA4B6pLY4adcjcQ728A6vgMWPv/g== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 07 Nov 2008 13:52:53.0968 (UTC) FILETIME=[21BD5D00:01C940E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3679; t=1226065974; x=1226929974; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=JWNjdAayhZ3OweG7WgYqbRfcZbQD8+0WghyxQI0OVZs=; b=ibFiHDhPUkQdTjkrhSuUk7m38+d5+7m2RH1VkN+TdCf8vN2wBOSGOnWPZn iKzCAeXV1hywSJmtDoKvfaNvBxKinPG5IcE2hVO9C3c1200xbZMJ4zkjda5Q AV4EoL9GAn; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi: My few cents: This doc is intended for standard track. As such we should be very careful = with what we actually specify. What I think we should be specifying is what= the metrics are, what they mean, and if possible an interoperable format f= or reporting them. How they can be used by a routing protocol could depend = on the routing protocol and I expect only guideline, not real specification. What they mean: -------------- Be very crisp. What do we count in transmission time, throughput etc... May= be we need to model a typical radio operation and discuss what is accounted= in which metric. For instance, we are using radios, time spent on CCA counts and the outgoin= g queueing delay (waiting for the channel to be free) is a good metric on l= ink utilization and capability to add / reserve new traffic. The recent exp= erience in backoff/retries counts. = If we are using slotted radios (TDM) then the actual time to access the out= going channel counts. The latency inside the device translates immediately = in buffer space that the device will typically lacks. How they can be used -------------------- Section 4 and 5 also are really informative. I expect recommendations in ch= apter 6 but fail to see why we are using uppercase MUST/SHOULD/RECOMMEND te= rms there; then again this is mostly informative. = I'd really wish to find some discussions on things like how can a link stat= e protocol manipulate statistical metrics, describing mechanisms such as hy= steresis (pro/con), triggered/piggy-backed updates (pro/con) etc... Is that= out of scope? Interoperable formats and operations ------------------------------------ This might be when we really need a standard track as opposed to informativ= e. = Knowing that a metric exists and what it is is a great step. Providing a in= teroperable format to exchange it and detailing the aggregation operation i= s needed as well if we want to standardize anything. We are used to metrics= where the representation is a flat number, and the aggregation as simple a= s the weakest link or the sum over the path. = But for the data that we are contemplating here things can rapidly get more= complex. For instance, for metrics that have a statistical aspect, I trust= that we need to exchange information such mean, mode or expected range (+/= - X percent) so that we do not need to update as long as we stay within ran= ge, that type of thing. = One advantage of doing that in a separate spec as opposed to each specific = routing protocol is to enable redistributing metrics between 2 different ro= uting protocols that would understand this spec but are designed differentl= y for different parts of the network (eg backbone vs. fringe). Then again is that out of scope? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mi= guel Sanchez >Sent: mercredi 29 octobre 2008 11:59 >To: ROLL WG >Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > >> So we would need your feed-back, bearing in mind that we may want to onl= y keep the metrics that are >critical to LLNs. >> > >Not sure what is the best way but being able to use remaining-energy >as a parameter for routing decisions maybe useful (if routing >contemplates that). Remaining node energy may be added to other >metrics (delay, traffic, PER, etc). > >Cheers, > >Miguel S=E1nchez >Universidad Polit=E9cnica de Valencia, Spain >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Nov 7 08:32:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34C63A6B5D; Fri, 7 Nov 2008 08:32:36 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D94A3A69DE for ; Fri, 7 Nov 2008 08:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOYVtHPJ1X8o for ; Fri, 7 Nov 2008 08:32:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4F7073A69B8 for ; Fri, 7 Nov 2008 08:32:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,565,1220227200"; d="scan'208,217";a="24997680" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2008 16:32:24 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA7GWO3d010472; Fri, 7 Nov 2008 17:32:24 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mA7GWOx3008637; Fri, 7 Nov 2008 16:32:24 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Nov 2008 17:32:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Nov 2008 17:32:00 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0683E061@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: Ack7FQze11sYPr2TQOCHDx1mJ+apwwFzcofw References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com><86c3ed7b0810300356s1e916d53ye3f3d93cc493838f@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "MiJeom Kim" , "Miguel Sanchez" X-OriginalArrivalTime: 07 Nov 2008 16:32:11.0096 (UTC) FILETIME=[623B5D80:01C940F6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18518; t=1226075544; x=1226939544; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=RqYtXumMvtKG2FLSr+lnbE0yJd0QuiP19BlO8mNs0wc=; b=Is2L4QysxJEem9drB0kwN6ktLLTnRycfVDsIV2a7sXvItTnLHFkRMZFDjS rIbyZwySan/ozHm0EinXZk95YU5T//1VG6vUfIZ6JAEMkSc26wkgn9+CZywr ZRUCh0dbgF; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0340653031==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0340653031== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C940F6.5E2E89F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C940F6.5E2E89F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mijeom, =20 I suspect that in many radio systems with operations similar to IEEE = 802, the propagation delay you are talking about is almost useless taken = separately since the transaction is only complete when an ack is = received back that enables a wireless router to free the resources = allocated to the frame and go back to sleep. The time between acking a = received frame and receiving the ack for that frame being forwarded is = the real latency of a node. If we want to sustain a given rate R with a = Latency L, we need R*L in buffer space. Considering that memory is often = a constrained resource this is something that we need to account for. =20 Pascal ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = MiJeom Kim Sent: vendredi 31 octobre 2008 05:56 To: Miguel Sanchez Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed =20 Hi, Miguel, =20 As I pointed out in my early posting, "Propagation delay" is just time a = packet to traverse a link. So it doesn't include transmission time. On = the other hand, node latency comprises transmission time, packet = processing time and queuing delay in section 4.4. In section 5.3, path = latency =3D propagation delay of all links + node latency of all nodes = along the path. Since propagation delay is negligible as Philip wrote = and it's hard to get its value, we might exclude the propagation delay = from routing metrics. Need more opinions. =20 Regarding the energy metric, I believe that there is a trade-off between = multi-threshold approaches and using numerical values. But, for = practical solutions, we might need to compromise precision by choosing = multi-threshold mechanisms.=20 =20 Thanks, Mijeom. On Thu, Oct 30, 2008 at 7:56 PM, Miguel Sanchez = wrote: Hi JP, On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur wrote: > Hi Miguel, > > > On 10/30/08 9:29 AM, "Miguel Sanchez" wrote: > >> I've got a terminology problem with "propagation delay" (5.3), while >> defined in the draft (and later defined is path propagation) a new >> meaning is given to the term. (For short range communications >> transmission time could be used instead). > > Let me make sure that I get your point here. The document says: > "Propagation delay is the time taken for the packet to traverse the > link from the source node to the target node." Definition is clear enough but what bothers me is that "propagation delay" equals link length over propagation speed in my book. Apparently the meaning here is more like transmission time + propagation delay (the latter as I've defined here). > > I think that the notion of source and target node is confusing and the = text > should read: > > " Propagation delay is the time taken for the packet to traverse the > link. " Do you mean including the transmission time? > > Does that clarify ? > >> >> Regarding the energy metric I can see a problem if only one value is >> given (ie: remaining enery). The value might be infinite to signal >> nodes without energy restrictions, but for the remaining nodes, a >> single value may not be enough. Let me elaborate on this with an >> example: A node may have an overall lower consumption than another >> one. If the former has slightly less energy than the second one, then >> choosing the later may not be the best choice for long term >> survivability of the network (this could be addressed by advertising >> expected node lifetime instead of node's remaining energy). >> > > Absolutely. The remaining energy metric may be difficult to interpret = and > the expected lifetime may be hard to compute. > >> On the other hand, without knowing the initial energy, it's not >> possible to know what fraction of the original energy is the = remaining >> one. This could be addressesed advertising remaining energy as a >> percentage (contrary to the above paragraph approach). > > Yes or ... We may use a simple multi-threshold mechanisms: "Low, = Medium, > High" where: > "LOW: avoid this node if possible" > "Medium: no particular constraint" > "HIGH: favor this node" > > Avoid/favor should of course be interpreted in the context of energy. > > What do you think ? I think the high/medium/low approach may hurt some implementations over a numerical value (i.e: choosing between two nodes with high value). > > But ... In any case, we need to avoid the definition of metric that = are > implementation/node dependent. The way you model energy cannot be > standardized. We've to find a way to create an standard way for energy reporting. = Haven't we? > > We also need to ensure that nodes use consistent metrics (a fairly = common > problem). > >> >> And last, in certain network setups some nodes may be easy to replace >> while others are not. You may want batteries to die out more often on >> nodes that can have their batteries replaced easily even though other >> nearby nodes have more energy available. > > Absolutely, as defined in the industrial routing requirement document. = This > should be an administrative constraint. > > Energy metric need to be >> complemented with other metrics. (Network survivability is not the >> only factor we have to take into account). > > Right. Did you have a look at the other ones ? I mostly agree with the rest, perhaps I'd chose PER (packet error rate) metric instead of BER. Regards, Miguel S=E1nchez > > Thanks. > > JP. > >> >> Regards, >> >> Miguel S=E1nchez >> >> ------_=_NextPart_001_01C940F6.5E2E89F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Mijeom,

 

I suspect that in many radio = systems with operations similar to IEEE 802, the propagation delay you are talking = about is almost useless taken separately since the transaction is only complete = when an ack is received back that enables a wireless router to free the = resources allocated to the frame and go back to sleep. The time between acking a = received frame and receiving the ack for that frame being forwarded is the real = latency of a node. If we want to sustain a given rate R with a Latency L, we need = R*L in buffer space. Considering that memory is often a constrained resource = this is something that we need to account for.

 

Pascal

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of MiJeom Kim
Sent: vendredi 31 octobre = 2008 05:56
To: Miguel Sanchez
Cc: ROLL WG
Subject: Re: [Roll] ROLL = Routing Metrics - WF feed-back needed

 

Hi, = Miguel,
 
As I pointed out in my early posting, "Propagation delay" is = just time a packet to traverse a link. So it doesn't include transmission = time. On the other hand, node latency comprises transmission time, packet = processing time and queuing delay in section 4.4. In section 5.3, path latency =3D propagation delay of all links + node latency of all nodes along the = path. Since propagation delay is negligible as Philip wrote and it's hard to get its = value, we might exclude the propagation delay from routing metrics. Need more opinions.
 
Regarding the energy metric, I believe that there is a trade-off between multi-threshold approaches and using numerical values. But, for = practical solutions, we might need to compromise precision by choosing = multi-threshold mechanisms.
 
Thanks,
Mijeom.

On Thu, Oct 30, 2008 at 7:56 PM, Miguel Sanchez <misan@disca.upv.es> = wrote:

Hi JP,


On Thu, Oct 30, 2008 at 10:02 AM, JP = Vasseur <jvasseur@cisco.com> = wrote:
> Hi Miguel,
>
>
> On 10/30/08 9:29 AM, "Miguel Sanchez" <misan@disca.upv.es> wrote:
>
>> I've got a terminology problem with "propagation = delay" (5.3), while
>> defined in the draft (and later defined is path propagation) a = new
>> meaning is given to the term. (For short range = communications
>> transmission time could be used instead).
>
> Let me make sure that I get your point here. The document says:
> "Propagation delay is the time taken for the packet to = traverse the
> link from the source node to the target = node."

Definition is clear enough but what bothers me is that "propagation
delay" equals link length over propagation speed in my book.
Apparently the meaning here is more like transmission time +
propagation delay (the latter as I've defined = here).

>
> I think that the notion of source and target node is confusing and = the text
> should read:
>
> " Propagation delay is the time taken for the packet to = traverse the
> link. "

Do you mean including the transmission = time?


>
> Does that clarify ?
>
>>
>> Regarding the energy metric I can see a problem if only one = value is
>> given (ie: remaining enery). The value might be infinite to = signal
>> nodes without energy restrictions, but for the remaining nodes, = a
>> single value may not be enough. Let me elaborate on this with = an
>> example: A node may have an overall lower consumption than = another
>> one. If the former has slightly less energy than the second = one, then
>> choosing the later may not be the best choice for long term
>> survivability of the network (this could be addressed by = advertising
>> expected node lifetime instead of node's remaining energy).
>>
>
> Absolutely. The remaining energy metric may be difficult to = interpret and
> the expected lifetime may be hard to compute.
>
>>  On the other hand, without knowing the initial energy, = it's not
>> possible to know what fraction of the original energy is the = remaining
>> one. This could be addressesed advertising remaining energy as = a
>> percentage (contrary to the above paragraph approach).
>
> Yes or ... We may use a simple multi-threshold mechanisms: = "Low, Medium,
> High" where:
> "LOW: avoid this node if possible"
> "Medium: no particular constraint"
> "HIGH: favor this node"
>
> Avoid/favor should of course be interpreted in the context of = energy.
>
> What do you think ?

I think the high/medium/low approach may hurt some = implementations
over a numerical value (i.e: choosing between two nodes with high
value).

>
> But ... In any case, we need to avoid the definition of metric that = are
> implementation/node dependent. The way you model energy cannot = be
> standardized.

We've to find a way to create an standard way for energy = reporting. Haven't we?


>
> We also need to ensure that nodes use consistent metrics (a fairly = common
> problem).
>
>>
>> And last, in certain network setups some nodes may be easy to = replace
>> while others are not. You may want batteries to die out more = often on
>> nodes that can have their batteries replaced easily even though = other
>> nearby nodes have more energy available.
>
> Absolutely, as defined in the industrial routing requirement = document. This
> should be an administrative constraint.
>
> Energy metric need to be
>> complemented with other metrics. (Network survivability is not = the
>> only factor we have to take into account).
>
> Right. Did you have a look at the other ones = ?

I mostly agree with the rest, perhaps I'd chose PER (packet = error
rate) metric instead of BER.

Regards,

Miguel S=E1nchez


>
> Thanks.
>
> JP.
>
>>
>> Regards,
>>
>> Miguel S=E1nchez
>>
>>

------_=_NextPart_001_01C940F6.5E2E89F8-- --===============0340653031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0340653031==-- From roll-bounces@ietf.org Fri Nov 7 11:53:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32633A6AE2; Fri, 7 Nov 2008 11:53:16 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955F63A6AE2 for ; Fri, 7 Nov 2008 11:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv6DK6Xz4YDm for ; Fri, 7 Nov 2008 11:53:14 -0800 (PST) Received: from mail.cs.wayne.edu (srv03fac.cs.wayne.edu [141.217.48.33]) by core3.amsl.com (Postfix) with ESMTP id 5498A3A695D for ; Fri, 7 Nov 2008 11:53:14 -0800 (PST) Received: from [172.30.6.13] ([141.217.48.171]) by mail.cs.wayne.edu (8.14.2/8.13.4) with ESMTP id mA7JqLfO014790; Fri, 7 Nov 2008 14:52:21 -0500 (EST) Message-ID: <49149C68.4090801@cs.wayne.edu> Date: Fri, 07 Nov 2008 14:52:08 -0500 From: Hongwei Zhang Organization: Wayne State University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0683DF47@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0683DF47@xmb-ams-337.emea.cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hongwei@wayne.edu List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1623593613==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1623593613== Content-Type: multipart/alternative; boundary="------------010506020400040309010003" This is a multi-part message in MIME format. --------------010506020400040309010003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit A minor point: It may well be worthwhile to define "packet format" in a way that enables us to introduce new metrics/attributes unforeseeable today. This is similar to the idea of "extension header" in IPv6. Hongwei Pascal Thubert (pthubert) wrote: >Hi: > >My few cents: > >This doc is intended for standard track. As such we should be very careful with what we actually specify. What I think we should be specifying is what the metrics are, what they mean, and if possible an interoperable format for reporting them. How they can be used by a routing protocol could depend on the routing protocol and I expect only guideline, not real specification. > >What they mean: >-------------- > >Be very crisp. What do we count in transmission time, throughput etc... Maybe we need to model a typical radio operation and discuss what is accounted in which metric. > >For instance, we are using radios, time spent on CCA counts and the outgoing queueing delay (waiting for the channel to be free) is a good metric on link utilization and capability to add / reserve new traffic. The recent experience in backoff/retries counts. > >If we are using slotted radios (TDM) then the actual time to access the outgoing channel counts. The latency inside the device translates immediately in buffer space that the device will typically lacks. > >How they can be used >-------------------- > >Section 4 and 5 also are really informative. I expect recommendations in chapter 6 but fail to see why we are using uppercase MUST/SHOULD/RECOMMEND terms there; then again this is mostly informative. > >I'd really wish to find some discussions on things like how can a link state protocol manipulate statistical metrics, describing mechanisms such as hysteresis (pro/con), triggered/piggy-backed updates (pro/con) etc... Is that out of scope? > >Interoperable formats and operations >------------------------------------ > >This might be when we really need a standard track as opposed to informative. > >Knowing that a metric exists and what it is is a great step. Providing a interoperable format to exchange it and detailing the aggregation operation is needed as well if we want to standardize anything. We are used to metrics where the representation is a flat number, and the aggregation as simple as the weakest link or the sum over the path. > >But for the data that we are contemplating here things can rapidly get more complex. For instance, for metrics that have a statistical aspect, I trust that we need to exchange information such mean, mode or expected range (+/- X percent) so that we do not need to update as long as we stay within range, that type of thing. > >One advantage of doing that in a separate spec as opposed to each specific routing protocol is to enable redistributing metrics between 2 different routing protocols that would understand this spec but are designed differently for different parts of the network (eg backbone vs. fringe). > >Then again is that out of scope? > >Pascal > > > >>-----Original Message----- >>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Miguel Sanchez >>Sent: mercredi 29 octobre 2008 11:59 >>To: ROLL WG >>Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> >> >> >>>So we would need your feed-back, bearing in mind that we may want to only keep the metrics that are >>> >>> >>critical to LLNs. >> >> >>Not sure what is the best way but being able to use remaining-energy >>as a parameter for routing decisions maybe useful (if routing >>contemplates that). Remaining node energy may be added to other >>metrics (delay, traffic, PER, etc). >> >>Cheers, >> >>Miguel Sánchez >>Universidad Politécnica de Valencia, Spain >>_______________________________________________ >>Roll mailing list >>Roll@ietf.org >>https://www.ietf.org/mailman/listinfo/roll >> >> >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll > > --------------010506020400040309010003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A minor point:
It may well be worthwhile to define "packet format" in a way that enables us to introduce new metrics/attributes unforeseeable today. This is similar to the idea of "extension header" in IPv6.

Hongwei


Pascal Thubert (pthubert) wrote:
Hi:

My few cents:

This doc is intended for standard track. As such we should be very careful with what we actually specify. What I think we should be specifying is what the metrics are, what they mean, and if possible an interoperable format for reporting them. How they can be used by a routing protocol could depend on the routing protocol and I expect only guideline, not real specification.

What they mean:
--------------

Be very crisp. What do we count in transmission time, throughput etc... Maybe we need to model a typical radio operation and discuss what is accounted in which metric.

For instance, we are using radios, time spent on CCA counts and the outgoing queueing delay (waiting for the channel to be free) is a good metric on link utilization and capability to add / reserve new traffic. The recent experience in backoff/retries counts. 

If we are using slotted radios (TDM) then the actual time to access the outgoing channel counts. The latency inside the device translates immediately in buffer space that the device will typically lacks.

How they can be used
--------------------

Section 4 and 5 also are really informative. I expect recommendations in chapter 6 but fail to see why we are using uppercase MUST/SHOULD/RECOMMEND terms there; then again this is mostly informative. 

I'd really wish to find some discussions on things like how can a link state protocol manipulate statistical metrics, describing mechanisms such as hysteresis (pro/con), triggered/piggy-backed updates (pro/con) etc... Is that out of scope?

Interoperable formats and operations
------------------------------------

This might be when we really need a standard track as opposed to informative. 

Knowing that a metric exists and what it is is a great step. Providing a interoperable format to exchange it and detailing the aggregation operation is needed as well if we want to standardize anything. We are used to metrics where the representation is a flat number, and the aggregation as simple as the weakest link or the sum over the path. 

But for the data that we are contemplating here things can rapidly get more complex. For instance, for metrics that have a statistical aspect, I trust that we need to exchange information such mean, mode or expected range (+/- X percent) so that we do not need to update as long as we stay within range, that type of thing. 

One advantage of doing that in a separate spec as opposed to each specific routing protocol is to enable redistributing metrics between 2 different routing protocols that would understand this spec but are designed differently for different parts of the network (eg backbone vs. fringe).

Then again is that out of scope?

Pascal

  
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Miguel Sanchez
Sent: mercredi 29 octobre 2008 11:59
To: ROLL WG
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

    
So we would need your feed-back, bearing in mind that we may want to only keep the metrics that are
      
critical to LLNs.
    
Not sure what is the best way but being able to use remaining-energy
as a parameter for routing decisions maybe useful (if routing
contemplates that). Remaining node energy may be added to other
metrics (delay, traffic, PER, etc).

Cheers,

Miguel Sánchez
Universidad Politécnica de Valencia, Spain
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
    
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------010506020400040309010003-- --===============1623593613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1623593613==-- From roll-bounces@ietf.org Fri Nov 7 12:58:15 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E790628C126; Fri, 7 Nov 2008 12:58:14 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165903A6B95 for ; Fri, 7 Nov 2008 12:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vnsq1Ydk1GdA for ; Fri, 7 Nov 2008 12:58:10 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 24AF13A6BA5 for ; Fri, 7 Nov 2008 12:58:10 -0800 (PST) Received: from [12.107.194.162] (helo=[192.168.5.105]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KyYP0-0004S0-R8; Fri, 07 Nov 2008 12:58:00 -0800 Message-Id: <2544B5EE-0EEB-4FA7-AAC7-AF99FC7B1B0E@cs.stanford.edu> From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0683E061@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 7 Nov 2008 12:57:53 -0800 References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com><86c3ed7b0810300356s1e916d53ye3f3d93cc493838f@mail.gmail.com> <7892795E1A87F04CADFCCF41FADD00FC0683E061@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: > Hi Mijeom, > > I suspect that in many radio systems with operations similar to IEEE > 802, the propagation delay you are talking about is almost useless > taken separately since the transaction is only complete when an ack > is received back that enables a wireless router to free the > resources allocated to the frame and go back to sleep. The time > between acking a received frame and receiving the ack for that frame > being forwarded is the real latency of a node. If we want to sustain > a given rate R with a Latency L, we need R*L in buffer space. > Considering that memory is often a constrained resource this is > something that we need to account for. Pascal, I'm not sure this is really an issue. You're talking about layer 2 acks? Generally those are always transmitted within a quite deterministic and tiny time interval; furthermore, media access is designed to prevent transmitting on top of them (e.g., through 15.4's double channel sense, or 802.11's NAV). The idea that a node has to hold onto a packet for a long time waiting for a layer 2 ack just isn't a problem, as they are generally synchronous rather than asynchronous (do not go through media access). Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Nov 9 22:07:07 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F643A6A2B; Sun, 9 Nov 2008 22:07:07 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628593A6A0D for ; Sun, 9 Nov 2008 22:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMEh0zGA7e3e for ; Sun, 9 Nov 2008 22:07:05 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 6B4243A6A2A for ; Sun, 9 Nov 2008 22:07:05 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1168285wag.5 for ; Sun, 09 Nov 2008 22:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=55AR4IcOhiGhfNFoUk2mB+cKjqyf9OE1Y9mmCglGTdM=; b=eFQiV74R3h0LAqCxCFO6i20olHxeR1sZPqVrRXdzmSAIfZL6vlsD+ltbrbETkyJu1V sl0WFXBozQHe7cVV1XmG6fPPiI1Aw1rudu4zoKRvkUDZI0oV4SKDkSN7uAb/R6f/xetG 8JZWesf/Cjskjw2L69wSZKCbSGFidI8CUz8Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=v5g8/4lzMrz2/0hRxvCeMZTAQyiQ/5SAMaVBhkdceE6or2nTdi8ou7gPEg4u+MwA9B QELyw8lGKY5pfLt2fQs90oXL76/YCqXZxwIY9h2CMi4kxBDMa3kHjc66Lg+c4OdFO1y4 m9Ji0/M02MbwkInGVjpS2EDMJzBtKDYRFYhS8= Received: by 10.115.22.1 with SMTP id z1mr3933673wai.60.1226297221107; Sun, 09 Nov 2008 22:07:01 -0800 (PST) Received: by 10.115.93.11 with HTTP; Sun, 9 Nov 2008 22:07:01 -0800 (PST) Message-ID: Date: Mon, 10 Nov 2008 15:07:01 +0900 From: "MiJeom Kim" To: "Philip Levis" In-Reply-To: <2544B5EE-0EEB-4FA7-AAC7-AF99FC7B1B0E@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810300356s1e916d53ye3f3d93cc493838f@mail.gmail.com> <7892795E1A87F04CADFCCF41FADD00FC0683E061@xmb-ams-337.emea.cisco.com> <2544B5EE-0EEB-4FA7-AAC7-AF99FC7B1B0E@cs.stanford.edu> Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, We have had quite a few arguments regarding delay related metrics through this mailing list. In traditional packet switched networks, there are four kinds of delays, which are processing delay, queuing delay, transmission delay and propagation delay. There is one more delay we make an issue here is L2 delay caused by MAC protocols. The document classifies the first three delays as node latency, one of node metrics and propagation delay as a link metric. Let's take into consideration one by one. - Processing delay: it's time for a node to process a packet including header analysis and error check. I personally prefer to exclude processing delay from metrics since it is kind of negligible and is depending on node's computing resource which is specified as a node metric. - Queuing delay: it is depending on time and current node workload (the number of packets arrived earlier), thus I prefer to exclude it, too. - Transmission delay: it's time to push the packet to the link and calculated as packet size/bit rate. It's a function of packet size, which is hard to make it a metric. We can take bit rate as a factor to affect link throughput, though. - Propagation delay: as we already agreed, it's close to light speed in radio systems and negligible. So I don't think we need this as a metric. - L2 delay: as I mentioned before, it's very fluctuating by time and depending on MAC protocols. Due to the all dependency I don't think it's a good idea to take L2 delay as a metric. To summary, delay related attributes are mostly varying as time and depending on variables such as packet size and workload. Therefore, I don't think anything above can be a feasible routing metric. Otherwise, we need really well designed schemes to take care of all the variables affecting the delays and to avoid instability, which is pretty skeptical. Always welcome other opinions, Thanks, Mijeom. On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis wrote: > > On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: > >> Hi Mijeom, >> >> I suspect that in many radio systems with operations similar to IEEE 802, >> the propagation delay you are talking about is almost useless taken >> separately since the transaction is only complete when an ack is received >> back that enables a wireless router to free the resources allocated to the >> frame and go back to sleep. The time between acking a received frame and >> receiving the ack for that frame being forwarded is the real latency of a >> node. If we want to sustain a given rate R with a Latency L, we need R*L in >> buffer space. Considering that memory is often a constrained resource this >> is something that we need to account for. > > Pascal, > > I'm not sure this is really an issue. You're talking about layer 2 acks? > Generally those are always transmitted within a quite deterministic and tiny > time interval; furthermore, media access is designed to prevent transmitting > on top of them (e.g., through 15.4's double channel sense, or 802.11's NAV). > The idea that a node has to hold onto a packet for a long time waiting for a > layer 2 ack just isn't a problem, as they are generally synchronous rather > than asynchronous (do not go through media access). > > Phil > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 00:56:37 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9383A68C6; Mon, 10 Nov 2008 00:56:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C2E3A68C6 for ; Mon, 10 Nov 2008 00:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDC9P1+VDtp0 for ; Mon, 10 Nov 2008 00:56:35 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9C30A3A6813 for ; Mon, 10 Nov 2008 00:56:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,574,1220227200"; d="scan'208";a="27293321" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2008 08:56:32 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAA8uWO8015401; Mon, 10 Nov 2008 03:56:32 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAA8uWQK025317; Mon, 10 Nov 2008 08:56:32 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 03:56:32 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Nov 2008 08:56:31 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 10 Nov 2008 09:56:30 +0100 From: JP Vasseur To: MiJeom Kim , Philip Levis Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclDEjjoJNR6m16X6USH2/iAB9Ccbw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 10 Nov 2008 08:56:32.0036 (UTC) FILETIME=[3A1F1E40:01C94312] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3861; t=1226307392; x=1227171392; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20MiJeom=20Kim=20,=20Philip=20Levis= 20; bh=Y3J9KovI4ZWG0PlsvlQFuXqhUZ1hhnEwdgJn5MspUhQ=; b=JQpFga4WY2fWpZMFDWcV/JT3DxVnIXO25R4ARyGHpSh755TOmLShtkyp1Q TSBynk+Qx1CWYrP3WmjK+LjyFprPmCuTvTyH5n6+3NUAA9hZko1i03bZLwjH 7F84Bhfr70; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Could you all have a look at all metrics and let us know which metrics you think that useful ? Then we start discussing how often they should be update for routing, packet format, .... Thanks. JP. On 11/10/08 7:07 AM, "MiJeom Kim" wrote: > Hi, > > We have had quite a few arguments regarding delay related metrics > through this mailing list. In traditional packet switched networks, > there are four kinds of delays, which are processing delay, queuing > delay, transmission delay and propagation delay. There is one more > delay we make an issue here is L2 delay caused by MAC protocols. The > document classifies the first three delays as node latency, one of > node metrics and propagation delay as a link metric. > > Let's take into consideration one by one. > - Processing delay: it's time for a node to process a packet including > header analysis and error check. I personally prefer to exclude > processing delay from metrics since it is kind of negligible and is > depending on node's computing resource which is specified as a node > metric. > - Queuing delay: it is depending on time and current node workload > (the number of packets arrived earlier), thus I prefer to exclude it, > too. > - Transmission delay: it's time to push the packet to the link and > calculated as packet size/bit rate. It's a function of packet size, > which is hard to make it a metric. We can take bit rate as a factor to > affect link throughput, though. > - Propagation delay: as we already agreed, it's close to light speed > in radio systems and negligible. So I don't think we need this as a > metric. > - L2 delay: as I mentioned before, it's very fluctuating by time and > depending on MAC protocols. Due to the all dependency I don't think > it's a good idea to take L2 delay as a metric. > > To summary, delay related attributes are mostly varying as time and > depending on variables such as packet size and workload. Therefore, I > don't think anything above can be a feasible routing metric. > Otherwise, we need really well designed schemes to take care of all > the variables affecting the delays and to avoid instability, which is > pretty skeptical. > > Always welcome other opinions, > > Thanks, > Mijeom. > > On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis wrote: >> >> On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Mijeom, >>> >>> I suspect that in many radio systems with operations similar to IEEE 802, >>> the propagation delay you are talking about is almost useless taken >>> separately since the transaction is only complete when an ack is received >>> back that enables a wireless router to free the resources allocated to the >>> frame and go back to sleep. The time between acking a received frame and >>> receiving the ack for that frame being forwarded is the real latency of a >>> node. If we want to sustain a given rate R with a Latency L, we need R*L in >>> buffer space. Considering that memory is often a constrained resource this >>> is something that we need to account for. >> >> Pascal, >> >> I'm not sure this is really an issue. You're talking about layer 2 acks? >> Generally those are always transmitted within a quite deterministic and tiny >> time interval; furthermore, media access is designed to prevent transmitting >> on top of them (e.g., through 15.4's double channel sense, or 802.11's NAV). >> The idea that a node has to hold onto a packet for a long time waiting for a >> layer 2 ack just isn't a problem, as they are generally synchronous rather >> than asynchronous (do not go through media access). >> >> Phil >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 01:34:44 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0153A6906; Mon, 10 Nov 2008 01:34:44 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58E53A694D for ; Mon, 10 Nov 2008 01:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGgOZqZOGdB1 for ; Mon, 10 Nov 2008 01:34:42 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 5A58A3A687A for ; Mon, 10 Nov 2008 01:34:41 -0800 (PST) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id mAA9Wv15010566; Mon, 10 Nov 2008 10:32:57 +0100 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id 28E0210C31D; Mon, 10 Nov 2008 10:32:57 +0100 (CET) From: "Mischa Dohler" To: "'MiJeom Kim'" , "'Philip Levis'" Date: Mon, 10 Nov 2008 10:29:02 +0100 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclC/G1RBE2Rbo/TQR+UlmIc6QsVUwAF0i4A In-Reply-To: Message-Id: <20081110093257.28E0210C31D@leo> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Mon, 10 Nov 2008 10:32:57 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: 'ROLL WG' Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Mijeom, all, the conclusion on the instability has - if I understood correctly - always been drawn assuming a fairly heavily loaded network. With some exceptions, however, our networks will be lightly loaded and duty-cycled, which means that in most cases the processing + queuing + transmission delay << L2 delay. Whilst this L2 delay heavily depends on the MAC, it is not a value which fluctuates strongly (if at all) over time. The end-to-end delay, will hence more or less be proportional to the number of hops multiplied by the L2 delay. Therefore, although differently motivated, I would agree that delay is not really needed. Having said this, in our urban scenario, delay is not really a design issue - Jerry, Kris and Anders may have a different opinion here. Regards, Mischa. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of MiJeom Kim Sent: Monday, November 10, 2008 7:07 AM To: Philip Levis Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Hi, We have had quite a few arguments regarding delay related metrics through this mailing list. In traditional packet switched networks, there are four kinds of delays, which are processing delay, queuing delay, transmission delay and propagation delay. There is one more delay we make an issue here is L2 delay caused by MAC protocols. The document classifies the first three delays as node latency, one of node metrics and propagation delay as a link metric. Let's take into consideration one by one. - Processing delay: it's time for a node to process a packet including header analysis and error check. I personally prefer to exclude processing delay from metrics since it is kind of negligible and is depending on node's computing resource which is specified as a node metric. - Queuing delay: it is depending on time and current node workload (the number of packets arrived earlier), thus I prefer to exclude it, too. - Transmission delay: it's time to push the packet to the link and calculated as packet size/bit rate. It's a function of packet size, which is hard to make it a metric. We can take bit rate as a factor to affect link throughput, though. - Propagation delay: as we already agreed, it's close to light speed in radio systems and negligible. So I don't think we need this as a metric. - L2 delay: as I mentioned before, it's very fluctuating by time and depending on MAC protocols. Due to the all dependency I don't think it's a good idea to take L2 delay as a metric. To summary, delay related attributes are mostly varying as time and depending on variables such as packet size and workload. Therefore, I don't think anything above can be a feasible routing metric. Otherwise, we need really well designed schemes to take care of all the variables affecting the delays and to avoid instability, which is pretty skeptical. Always welcome other opinions, Thanks, Mijeom. On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis wrote: > > On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: > >> Hi Mijeom, >> >> I suspect that in many radio systems with operations similar to IEEE 802, >> the propagation delay you are talking about is almost useless taken >> separately since the transaction is only complete when an ack is received >> back that enables a wireless router to free the resources allocated to the >> frame and go back to sleep. The time between acking a received frame and >> receiving the ack for that frame being forwarded is the real latency of a >> node. If we want to sustain a given rate R with a Latency L, we need R*L in >> buffer space. Considering that memory is often a constrained resource this >> is something that we need to account for. > > Pascal, > > I'm not sure this is really an issue. You're talking about layer 2 acks? > Generally those are always transmitted within a quite deterministic and tiny > time interval; furthermore, media access is designed to prevent transmitting > on top of them (e.g., through 15.4's double channel sense, or 802.11's NAV). > The idea that a node has to hold onto a packet for a long time waiting for a > layer 2 ack just isn't a problem, as they are generally synchronous rather > than asynchronous (do not go through media access). > > Phil > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 04:45:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFCF3A6949; Mon, 10 Nov 2008 04:45:39 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCED3A6949 for ; Mon, 10 Nov 2008 04:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxSdlhDhDMEi for ; Mon, 10 Nov 2008 04:45:34 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 712273A6940 for ; Mon, 10 Nov 2008 04:45:34 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KzW95-00080v-BW; Mon, 10 Nov 2008 04:45:31 -0800 Message-Id: <919A84B1-BCBA-4452-9C8A-5BFE6D1E0C18@cs.stanford.edu> From: Philip Levis To: In-Reply-To: <20081110093257.28E0210C31D@leo> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 04:45:33 -0800 References: <20081110093257.28E0210C31D@leo> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: 'ROLL WG' Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 10, 2008, at 1:29 AM, Mischa Dohler wrote: > Hi Mijeom, all, the conclusion on the instability has - if I > understood > correctly - always been drawn assuming a fairly heavily loaded > network. With > some exceptions, however, our networks will be lightly loaded and > duty-cycled, which means that in most cases the processing + queuing + > transmission delay << L2 delay. Whilst this L2 delay heavily depends > on the > MAC, it is not a value which fluctuates strongly (if at all) over > time. The > end-to-end delay, will hence more or less be proportional to the > number of > hops multiplied by the L2 delay. Therefore, although differently > motivated, > I would agree that delay is not really needed. Having said this, in > our > urban scenario, delay is not really a design issue - Jerry, Kris and > Anders > may have a different opinion here. Regards, Mischa. It is proportional, in that if you add a hop it will become longer, but that doesn't mean it's a linear function. Consider a standard TDMA MAC layer which uses communication slots; if slots are distributed in, say, a 250ms cycle, then the MAC latency at one hop can be 0-250ms. In such a network, minimizing latency might lead to different routes than minimizing cost (transmissions). Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 07:55:43 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812B83A6A27; Mon, 10 Nov 2008 07:55:43 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296613A6965 for ; Mon, 10 Nov 2008 07:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BxVYM6vEvY1 for ; Mon, 10 Nov 2008 07:55:39 -0800 (PST) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 0A5103A6A27 for ; Mon, 10 Nov 2008 07:55:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Nov 2008 16:55:29 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429312@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclASyGEMTjY8xFnTCOz0i/kZ1ya1QC/GiSw References: <49126E8D.5030306@eecs.berkeley.edu> From: "Anders Brandt" To: , "Kris Pister" Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1882456433==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1882456433== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9434C.C11CC50A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9434C.C11CC50A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jerry touches a point I forgot to mention in relation to Kris' previous postings. I fully support the idea of preferred routers running on battery. We definitely also see this application in the home control domain. =20 > ...let's say I have a battery powered repeater installed in a sparse portion of the mesh. This device has no other meaning in > life but to route messages. Rerouting around this device saves the energy on a device that has no reason to save energy. > Also, remember this repeater was strategically placed to 'fill-in' the mesh. =20 In order to attract interest from the routing protocol, such a node should be able to signal "mains powered" or even better: "I have plenty of battery". Obviously, it should lower that indication to normal "battery-powered" if running close to low; ending with "battery low". br. Anders =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: 6. november 2008 21:04 To: Kris Pister Cc: ROLL WG; Ted.Humpal@jci.com Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Kris,=20 I'm getting your point, to a point...=20 First off, in the Commercial Building market, all routering devices will be lines powered and hence the routing protocol need not concern itself with power starved routers. You must be vying for some sort of synchronous network where the routers power up on a very short duty cycle. Our radios typically require 10000x more energy (~27ma) when powered up and transmitting or receiving than asleep (2uA). You would blow out the joules of any reasonably sized battery quite quickly if the receiver needed to be on for extended periods on the off-chance that a message needed to be routered through it. =20 As for the routing protocol needing a priori knowledge of the battery status of a device to determine selected paths, I still don't see this as a network routing parameter. The node that becomes energy starved simply needs to stop forwarding routed messages. The transport will quickly notice that messages are not reaching their destination and advertise for a new path to which our energy starved device won't respond. A more graceful approach would be for the energy starved node to simply tell the source node that it is temporarily out of the routering business. This functionality needs to be in place anyway since even in normal operation, an existing path might get blocked.=20 By advertising remaining energy throughout the network and making systemic routing choices based on available energy seems like a nice thing to do and would tend to balance the total available energy across the mesh. However, the network also must understand the application running on the node to make the choice. For example, let's say I have a battery powered repeater installed in a sparse portion of the mesh. This device has no other meaning in life but to route messages. Rerouting around this device saves the energy on a device that has no reason to save energy. Also, remember this repeater was strategically placed to 'fill-in' the mesh. By taking it out of the mesh routes, all the other nodes will need to use up more of their available energy to make up for this missing node.=20 Conversely, (kind of!!!) let's say I have a sensor that needs to report status temporally. Even if I stop routing, I still need to awaken to do my own task on a periodic basis. In many cases I can synchronize my application with the duty cycle of the network. Now I can continue to perform both jobs without reducing energy any more than I would performing my one required job.=20 My point being that it is important to understand the application requirements as well as battery status to make judicious routing decisions. Why not let each device decide no its own if it can save power by taking itself out of the routing paths. The mesh would then just re-form as needed around the devices.=20 Jerry=20 Kris Pister =20 11/05/2008 10:08 PM=20 To Jerald.P.Martocci@jci.com=20 cc ROLL WG =20 Subject Re: [Roll] ROLL Routing Metrics - WF feed-back needed =09 Jerry - I'm not trying to get the IETF decide the threshold for any=20 flags. My point is that a single bit flag is virtually useless for=20 making intelligent routing decisions, regardless of what threshold value you choose for it. You say that remaining energy is not a function of time, and yet the=20 units you use to describe where you set the threshold are "months" :) =20 Somehow we have to make the same kind of translations between Joules and months, and for networks where the routers are battery powered, this IS=20 a routing issue. Here's why: ignoring energy in routing decisions, protocol X creates=20 networks that have a distribution of lifetimes varying, for example,=20 from three to fifteen years. Protocol Y, using energy in its routing=20 decisions, builds networks that have the same mean lifetime, but a=20 distribution that is much tighter - from 9 to 12 years. Which one would you rather buy? One where you start replacing batteries after 3 years,=20 or one were you replace them all at 9 years? ksjp Jerald.P.Martocci@jci.com wrote: > > Why is the IETF trying to establish when the energy flag needs to be=20 > set for low battery? This is an application issue. =20 > > Remaining energy is not a function of time, it's a function of=20 > remaining energy. In our current wireless products, we have a=20 > comparator that will shut the sensor down at a given voltage level.=20 > We have actually calculated the number of joules required per=20 > transaction and have back calculated the voltage level at which point=20 > we will issue a low-battery alarm. We set the voltage level to alarm=20 > about 3 months before the device shuts down, giving the customer 3=20 > months to change the battery. This is for a device that transmits=20 > once a minute for about 3 msecs. The battery status is included=20 > (1-bit). with every transaction. Two alkaline 'c' cells will last=20 > about 10 years, but due to shelf life, we specify 5 year battery life. > > From my viewpoint all battery powered wireless devices need to=20 > transmit their battery status. For interoperability purposes, this=20 > should be dictated. However, this is not a protocol issue, much less=20 > a routing issue. This should be something done by the implementers or > specified at the alliance level (e.g. IPSO). > > Jerry > > > > > > *Kris Pister * > Sent by: roll-bounces@ietf.org > > 11/04/2008 06:06 PM > > =20 > To > JP Vasseur > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > =20 > > > > > > Well, we both agree that there will be load imbalance and differential > rate of energy consumption, > and we both agree that oscillations will be bad. I think that we may=20 > have a different picture of the > frequency of those oscillations, though. I think that most/all of the > systems described in the > requirements docs have battery lifetime requirements measured in=20 > years. This implies a minimum > update rate of, oh, something like monthly. Sending a few tens of=20 > bytes of data describing > energy and power state on a daily basis is both far more frequent than > we need, and unlikely > to cause *wasteful* oscillations. If there is some route bouncing=20 > with a one day or week period, maybe > that's actually optimal. It's certainly not expensive. > > I'm still very curious as to where you think that we should set the=20 > "low energy" flag level. Based on the two scenarios that I presented, > I don't see that single-bit flags have much value. As you pointed out > in your response, the traffic will not be balanced. Either I set the=20 > flag near midpoint, and it doesn't help much, or I set well below=20 > midpoint, and it doesn't help very much. > > I can imagine scenarios in which it works great. Unfortunately,=20 > working well 50% of the time doesn't do us much good. We don't have=20 > to handle every situation, but we have to at least deal with common=20 > problems that come up in real networks. > > ksjp > > JP Vasseur wrote: > Hi Kris, > > > On 11/4/08 6:28 AM, "Kris Pister" __=20 > wrote: > > =20 > JP - I'd like to understand more about your flags. > If I have a network in which I expect that all motes last for 7 years, > where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 > years)? At 5% (ideally 3 months)? > In the first case, for roughly half of my network lifetime, all of my > network will have set the "I'm low on energy" flag, and I will have no > useful information with which to make routing decisions. > In the second case, I have almost no useful information until it's too > late - one year into operation and several of the busiest motes are > almost dead, while a mote with a much bigger battery still has almost > all of it's charge. So in this case the information shows up too late > to be useful. > I'm sure that's not the way you see it. What am I missing? > > =20 > > See it as a trade-off between frequent accurate updates (=3D> = requiring > energy, risk of routing oscillations, ...) and no information at all.=20 > If you > make the assumption of uniform energy consumption, then flags are always > useless (so does more up to date data). On the other hand if you see=20 > the use > of such flags as safeguard mechanisms, this could be useful to start > rerouting the traffic around nodes running out of battery. Suppose=20 > that the > traffic is not equally balanced in the network, you may end up with nodes > consuming battery at a much higher rates than others, in which case the > flags may be useful, with no risk of oscillation. > > Thoughts ? > > Cheers, > > JP. > > =20 > ksjp > > JP Vasseur wrote: > =20 > Hi Miguel, > > > On 10/31/08 12:24 PM, "Miguel Sanchez" __=20 > wrote: > > =20 > =20 > Hi JP, > > > > On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur __=20 > wrote: > =20 > =20 > Hi Kris, > > > On 10/30/08 5:33 PM, "Kris Pister" __=20 > wrote: > > I agree with Miguel that we need a standard way of energy reporting, and I > agree with JP that it's hard to do. > Part of the challenge is that energy sources and storage vary so much. We > have: > * line power - great if you can get it! > * battery storage > - this is time varying. The available energy in a battery is a > strong > function of the temperature and the usage profile. So a battery powered > mote may correctly calculate five years of lifetime in summer, and then > that > winter under the exact same load conditions it may correctly calculate a > lifetime of ten years. The same mote with the same battery may have=20 > better > performance in summer at higher loads. > > JP> and usage profile may also change. > > * capacitive storage > * energy scavenging > - this is time varying, and tough to bound (usefully > > JP> this is why I'm questioning the usefulness of knowing the remaining > energy expressed in Joules or other metrics. Knowing this value will not > tell you anything as to whether you should or should not use that node > when > computing the path. Another metric may be the remaining estimated lifetime > =20 > =20 > I disagree. > > At least if remaining energy is infinitum (mains powered) tells you > something. > > OTOH, if limited, depending on other properties of the nodes (like > where it gets its energy from) it is also useful for making routing > decisions too. > =20 > =20 > OK let's try to step back. I'm proposing a flag-based mechanism to=20 > avoid the > use of a node should this node run out of energy. The decision to set the > flag is made by the node (no specified) according to many parameters > (estimated like time, ... Etc). Some nodes having more power may make=20 > use of > complex models. > > If you advertise your remaining power in Joules, how would you expect the > nodes to change their routing decisions since they have no idea of whether > you are running low in energy (it highly depends on what the node=20 > does, the > external conditions, ... Etc) ? > > Thanks. > > JP. > > =20 > =20 > but still, is the node capable (without consuming too much energy) of > gathering historical data etc ... to provide an accurate value hoping that > other criterion such as usage profile or temperature as you pointed out > will > not change ? > > All of this makes energy/power/lifetime reporting painful, yet I can not > picture a successful routing protocol that doesn't somehow take these > factors into account. > > =20 > =20 > Kind regards, > > Miguel > =20 > =20 > =20 > =20 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------_=_NextPart_001_01C9434C.C11CC50A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jerry touches a point I forgot to mention in = relation=20 to Kris' previous postings.

I fully support the idea of preferred = routers=20 running on battery.
We definitely also see this application in the = home=20 control domain.
 
> ...let's say I = have a battery=20 powered repeater installed in a sparse portion of the mesh.  This = device=20 has no other meaning in
> life but to route = messages. Rerouting=20 around this device saves the energy on a device that has no reason to = save=20 energy.
>  Also, remember this repeater was strategically = placed to=20 'fill-in' the mesh.
 
In=20 order to attract interest from the routing protocol, such a node should = be able=20 to signal "mains powered" or even better:
"I have plenty of=20 battery".
Obviously, it should lower that indication to = normal=20 "battery-powered" if running close to low; ending with "battery=20 low".
br.=20 Anders

 
From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com
Sent: 6. november 2008=20 21:04
To: Kris Pister
Cc: ROLL WG;=20 Ted.Humpal@jci.com
Subject: Re: [Roll] ROLL Routing Metrics - = WF=20 feed-back needed


Kris,=20

I'm getting your point, to a=20 point...

First off, in = the=20 Commercial Building market, all routering devices will be lines powered = and=20 hence the routing protocol need not concern itself with power starved = routers.=20  You must be vying for some sort of synchronous network where the = routers=20 power up on a very short duty cycle.  Our radios typically require = 10000x=20 more energy (~27ma) when powered up and transmitting or receiving =  than=20 asleep (2uA).  You would blow out the joules of any reasonably = sized=20 battery quite quickly if the receiver needed to be on for extended = periods on=20 the off-chance that a message needed to be routered through it. =  =20

As for the routing protocol = needing a=20 priori knowledge of the battery status of a device to determine selected = paths,=20 I still don't see this as a network routing parameter.  The node = that=20 becomes energy starved simply needs to stop forwarding routed messages. =  =20 The transport will quickly notice that messages are not reaching their=20 destination and advertise for a new path to which our energy starved = device=20 won't respond.  A more graceful approach would be for the energy = starved=20 node to simply tell the source node that it is temporarily out of the = routering=20 business.  This functionality needs to be in place anyway since = even in=20 normal operation, an existing path might get blocked. =

By advertising remaining energy throughout = the network=20 and making systemic routing choices based on available energy seems like = a nice=20 thing to do and would tend to balance the total available energy across = the=20 mesh.  However, the network also must understand the application = running on=20 the node to make the choice.  For example, let's say I have a = battery=20 powered repeater installed in a sparse portion of the mesh.  This = device=20 has no other meaning in life but to route messages.  Rerouting = around this=20 device saves the energy on a device that has no reason to save energy.=20  Also, remember this repeater was strategically placed to 'fill-in' = the=20 mesh.  By taking it out of the mesh routes, all the other nodes = will need=20 to use up more of their available energy to make up for this missing=20 node.

Conversely, (kind = of!!!) let's=20 say I have a sensor that needs to report status temporally.  Even = if I stop=20 routing, I still need to awaken to do my own task on a periodic basis. =  In=20 many cases I can synchronize my application with the duty cycle of the = network.=20  Now I can continue to perform both jobs without reducing energy = any more=20 than I would performing my one required job.

My point being that it is important to = understand the=20 application requirements as well as battery status to make judicious = routing=20 decisions.  Why not let each device decide no its own if it can = save power=20 by taking itself out of the routing paths.  The mesh would then = just=20 re-form as needed around the devices.

Jerry




Kris Pister=20 <pister@eecs.berkeley.edu>

11/05/2008 10:08 PM =

To
Jerald.P.Martocci@jci.com=20
cc
ROLL WG=20 <roll@ietf.org>=20
Subject
Re: [Roll] ROLL Routing = Metrics -=20 WF feed-back needed

=




Jerry - I'm not trying to get the IETF decide the threshold = for any=20
flags.  My point is that a single bit flag is virtually useless = for=20
making intelligent routing decisions, regardless of what threshold = value=20
you choose for it.

You say that remaining energy is not a = function of=20 time, and yet the
units you use to describe where you set the = threshold are=20 "months" :)  
Somehow we have to make the same kind of = translations=20 between Joules and
months, and for networks where the routers are = battery=20 powered, this IS
a routing issue.

Here's why: ignoring energy = in=20 routing decisions, protocol X creates
networks that have a = distribution of=20 lifetimes varying, for example,
from three to fifteen years. =  Protocol=20 Y, using energy in its routing
decisions, builds networks that have = the same=20 mean lifetime, but a
distribution that is much tighter - from 9 to = 12 years.=20  Which one would
you rather buy?  One where you start = replacing=20 batteries after 3 years,
or one were you replace them all at 9=20 years?

ksjp

Jerald.P.Martocci@jci.com = wrote:
>
> Why=20 is the IETF trying to establish when the energy flag needs to be =
> set=20 for low battery?  This is an application issue. =  
>
>=20 Remaining energy is not a function of time, it's a function of
>=20 remaining energy.  In our current wireless products, we have a =
>=20 comparator that will shut the sensor down at a given voltage level. =
>=20  We have actually calculated the number of joules required per =
>=20 transaction and have back calculated the voltage level at which point =
>=20 we will issue a low-battery alarm.  We set the voltage level to = alarm=20
> about 3 months before the device shuts down, giving the = customer 3=20
> months to change the battery.  This is for a device that = transmits=20
> once a minute for about 3 msecs.  The battery status is = included=20
> (1-bit). with every transaction.  Two alkaline  'c' = cells=20 will last
> about 10 years, but due to shelf life, we specify 5 = year=20 battery life.
>
> From my viewpoint all battery powered = wireless=20 devices need to
> transmit their battery status.  For=20 interoperability purposes, this
> should be dictated. =  However, this=20 is not a protocol issue, much less
> a routing issue.  This = should=20 be something done by the implementers or
> specified at the = alliance=20 level (e.g. IPSO).
>
>=20 Jerry
>
>
>
>
>
> *Kris Pister=20 <pister@eecs.berkeley.edu>*
> Sent by:=20 roll-bounces@ietf.org
>
> 11/04/2008 06:06 = PM
>
>  =20                
> = To
>=20                  JP Vasseur = <jvasseur@cisco.com>
> cc
>       =    =20        ROLL WG <roll@ietf.org>
> = Subject
>=20                  Re: [Roll] = ROLL=20 Routing Metrics - WF feed-back needed
>
>
>
> =  =20              =20  
>
>
>
>
>
> Well, we both = agree that=20 there will be load imbalance and differential
> rate of energy=20 consumption,
> and we both agree that oscillations will be bad. =  I=20 think that we may
> have a different picture of the
> = frequency of=20 those oscillations, though.  I think that most/all of the
> = systems=20 described in the
> requirements docs have battery lifetime = requirements=20 measured in
> years.  This implies a minimum
> update = rate of,=20 oh, something like monthly.  Sending a few tens of
> bytes = of data=20 describing
> energy and power state on a daily basis is both far = more=20 frequent than
> we need, and unlikely
> to cause *wasteful* = oscillations.  If there is some route bouncing
> with a one = day or=20 week period, maybe
> that's actually optimal.  It's certainly = not=20 expensive.
>
> I'm still very curious as to where you think = that we=20 should set the
> "low energy" flag level.  Based on the two=20 scenarios that I presented,
> I don't see that single-bit flags = have much=20 value.  As you pointed out
> in your response, the traffic = will not=20 be balanced.  Either I set the
> flag near midpoint, and it = doesn't=20 help much, or I set well below
> midpoint, and it doesn't help = very=20 much.
>
> I can imagine scenarios in which it works great.=20  Unfortunately,
> working well 50% of the time doesn't do us = much=20 good.  We don't have
> to handle every situation, but we = have to at=20 least deal with common
> problems that come up in real=20 networks.
>
> ksjp
>
> JP Vasseur wrote:
> = Hi=20 Kris,
>
>
> On 11/4/08 6:28 AM, "Kris Pister"=20 _<pister@eecs.berkeley.edu>_
>=20 <mailto:pister@eecs.berkeley.edu> wrote:
>
> =  
> JP=20 - I'd like to understand more about your flags.
> If I have a = network in=20 which I expect that all motes last for 7 years,
> where do I set = the "I'm=20 low on energy" flag?  At 50% (ideally 3.5
> years)?  At = 5%=20 (ideally 3 months)?
> In the first case, for roughly half of my = network=20 lifetime, all of my
> network will have set the "I'm low on = energy" flag,=20 and I will have no
> useful information with which to make routing = decisions.
> In the second case, I have almost no useful = information until=20 it's too
> late - one year into operation and several of the = busiest motes=20 are
> almost dead, while a mote with a much bigger battery still = has=20 almost
> all of it's charge.  So in this case the information = shows=20 up too late
> to be useful.
> I'm sure that's not the way = you see=20 it.  What am I missing?
>
>   =  
>
> See=20 it as a trade-off between frequent accurate updates (=3D> = requiring
>=20 energy, risk of routing oscillations, ...) and no information at all. =
>=20 If you
> make the assumption of uniform energy consumption, then = flags are=20 always
> useless (so does more up to date data). On the other hand = if you=20 see
> the use
> of such flags as safeguard mechanisms, this = could=20 be useful to start
> rerouting the traffic around nodes running = out of=20 battery. Suppose
> that the
> traffic is not equally = balanced in=20 the network, you may end up with nodes
> consuming battery at a = much=20 higher rates than others, in which case the
> flags may be useful, = with no=20 risk of oscillation.
>
> Thoughts ?
>
>=20 Cheers,
>
> JP.
>
>  
> = ksjp
>
>=20 JP Vasseur wrote:
>    
> Hi=20 Miguel,
>
>
> On 10/31/08 12:24 PM, "Miguel Sanchez"=20 _<misan@disca.upv.es>_
> <mailto:misan@disca.upv.es>=20 wrote:
>
>  
>      
> Hi=20 JP,
>
>
>
> On Fri, Oct 31, 2008 at 12:14 PM, JP = Vasseur=20 _<jvasseur@cisco.com>_
> <mailto:jvasseur@cisco.com>=20 wrote:
>    
>        
> = Hi=20 Kris,
>
>
> On 10/30/08 5:33 PM, "Kris Pister"=20 _<pister@eecs.berkeley.edu>_
>=20 <mailto:pister@eecs.berkeley.edu> wrote:
>
> I agree = with=20 Miguel that we need a standard way of energy reporting, and I
> = agree with=20 JP that it's hard to do.
> Part of the challenge is that energy = sources=20 and storage vary so much. We
> have:
> * line power - great = if you=20 can get it!
> * battery storage
>      - this = is time=20 varying.  The available energy in a battery is a
> = strong
>=20 function of the temperature and the usage profile.  So a battery=20 powered
> mote may correctly calculate five years of lifetime in = summer,=20 and then
> that
> winter under the exact same load = conditions it may=20 correctly calculate a
> lifetime of ten years.  The same mote = with=20 the same battery may have
> better
> performance in summer = at=20 higher loads.
>
> JP> and usage profile may also=20 change.
>
> * capacitive storage
> * energy = scavenging
>=20      - this is time varying, and tough to bound=20 (usefully
>
> JP> this is why I'm questioning the = usefulness of=20 knowing the remaining
> energy expressed in Joules or other = metrics.=20 Knowing this value will not
> tell you anything as to whether you = should=20 or should not use that node
> when
> computing the path. = Another=20 metric may be the remaining estimated lifetime
>    =20  
>          
> I=20 disagree.
>
> At least if remaining energy is infinitum = (mains=20 powered) tells you
> something.
>
> OTOH, if limited,=20 depending on other properties of the nodes (like
> where it gets = its=20 energy from) it is also useful for making routing
> decisions = too.
>=20    
>        
> OK let's try = to step=20 back. I'm proposing a flag-based mechanism to
> avoid the
> = use of=20 a node should this node run out of energy. The decision to set = the
> flag=20 is made by the node (no specified) according to many parameters
>=20 (estimated like time, ... Etc). Some nodes having more power may make =
>=20 use of
> complex models.
>
> If you advertise your = remaining=20 power in Joules, how would you expect the
> nodes to change their = routing=20 decisions since they have no idea of whether
> you are running low = in=20 energy (it highly depends on what the node
> does, the
> = external=20 conditions, ... Etc) ?
>
> Thanks.
>
>=20 JP.
>
>  
>      
> but = still, is=20 the node capable (without consuming too much energy) of
> = gathering=20 historical data etc ... to provide an accurate value hoping that
> = other=20 criterion such as usage profile or temperature as you pointed = out
>=20 will
> not change ?
>
> All of this makes=20 energy/power/lifetime reporting painful, yet I can not
> picture a = successful routing protocol that doesn't somehow take these
> = factors into=20 account.
>
>      
>     =  =20    
> Kind regards,
>
> Miguel
> =  =20  
>        
>  
>   =  =20  
>
>=20  _______________________________________________
> Roll = mailing=20 list
> Roll@ietf.org
>=20 https://www.ietf.org/mailman/listinfo/roll
>

------_=_NextPart_001_01C9434C.C11CC50A-- --===============1882456433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1882456433==-- From roll-bounces@ietf.org Mon Nov 10 08:21:38 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01553A6965; Mon, 10 Nov 2008 08:21:38 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FBB28C0D0 for ; Mon, 10 Nov 2008 08:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADpFDrPShx7X for ; Mon, 10 Nov 2008 08:21:36 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 937813A68AE for ; Mon, 10 Nov 2008 08:21:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C9312AF882; Mon, 10 Nov 2008 08:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KYWgH9jsfxH; Mon, 10 Nov 2008 08:21:33 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 259F7AF869; Mon, 10 Nov 2008 08:21:33 -0800 (PST) Message-Id: <2853C451-5AD6-4650-B5E2-AB3DFB1D0494@archrock.com> From: Jonathan Hui To: MiJeom Kim In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 08:21:31 -0800 References: <628C538F-D023-482F-8C94-047D87A49DDC@archrock.com> X-Mailer: Apple Mail (2.929.2) Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi MiJeom, see below: On Nov 3, 2008, at 11:46 PM, MiJeom Kim wrote: > Hi, Jonathan, really appriciate your valuable comments. Please see > below. > > On Tue, Nov 4, 2008 at 3:02 AM, Jonathan Hui > wrote: >> >> - Section 4.3 and 4.4: I understand that these are important >> metrics with more traditional (higher power) link technologies, but >> I think the description does not sufficiently characterize the >> challenges in LLNs. In general, most of the high-order bits in >> these metrics will be due to communication delays at the link layer >> (scheduled communication as well as conservative backoffs can cause >> communication delays on the order of seconds and even 10s of >> seconds). This can easily dwarf all other delays caused by >> processing times. For the networks I'm used to dealing with, I'd >> argue that communication latency is much more significant than node >> workload. >> >> ==> I totally agree on what you said here. However, L2 delay >> depends on MAC protocols and it's very fluctuating by time. If >> there is high contention for a given channel, it takes more time to >> send a packet with contention based protocols. In contention-free >> protocols, L2 delay is more predictable and consistent. Due to the >> all dependency, I do not think it is possible to make L2 delay as a >> routing metric. [jhui] There are significant constant factors that we can consider when considering L2 delay - duty cycle and phase. Both of which determine the *minimum* latency. Both of which can be on the order of seconds or more. >> - Section 4.5: I'm not convinced that the Data Aggregation >> attribute is best to have within the network layer. Data >> aggregation is application specific. The great thing about route- >> over is that it exposes all of the physical connectivity above IP, >> and doing so supports the construction of higher-layer structures >> (i.e. overlays) that can support things like in-network processing. >> I personally feel that data aggregation is best left for higher >> layers. >> >> ==> I agree that data aggregation is application or traffic >> dependent. Let's hear other's opinion. [jhui] In some cases, unicast routing is not always the best way to aggregate information between nodes that are within physical proximity. >> - Section 4.6: I share the same concern with Phil. While even DV >> protocols maintain neighbors, the strict resource constraints of >> LLNs often restrict nodes to maintaining state about a *subset* of >> their neighbors. I do believe that maintaining a node's degree in >> terms of bi-directional links will not fit within the resource >> constraints of typical LLNs in the general case. However, degree is >> a useful metric to have, if we can both define and evaluate it >> properly. >> >> ==> As I mentioned already, we need to reach consensus on the way >> to evaluate node degree. Higher degree would be preferable, but >> does this apply for all situations? Also, we need to evaluate trade- >> off between cost and benefit of using node degree as a metric. [jhui] Yes. What is degree, really? All nodes that can communicate to A? All nodes that A can communicate to? Both? These definitions have subtle differences on the use of a degree metric and that is dependent on the L2 capabilities below. >> - Section 4.7: Agreeing with what was mentioned earlier on the >> list, the distinction between Dynamicity (4.7) and Link >> Reliability (5.2) is not obvious to me. In some sense, we have only >> marginal control over network topology and node behaviors - they >> are often driven by surrounding environmental factors. >> >> ==> we can't control the dynamicity or reliability. We just need to >> monitor and estimate them to construct a better path by avoiding >> highly dynamic and unreliable nodes. We need to have clear >> definitions for them and methods to measure them, which is >> challenging. [jhui] That's exactly my point. The way we monitor dynamicity and reliability may be very similar... >> - Section 5.1: I think the metric we really want here is >> throughput. Bandwidth is only one of many factor that affects the >> link's throughput. >> >> ==> I agree. Actual average data rate can be one factor to affect >> the throughput. Do you have other factors in your mind? [jhui] The L2 protocol is the largest factor in what throughput you can expect on that link. >> - Section 5.2: Just a personal opinion here, but I strongly believe >> that bi-directional link success rates (PRR) will be much more >> useful than directional success rates. Due to the lossy nature of >> LLNs, I expect most, if not all, LLNs to utilize link-layer >> acknowledgments. Furthermore, enforcing metrics to be bi- >> directional have significant simplification advantages with respect >> to routing. >> >> ===> I do agree, but maintaining bi-directional metrics costs more >> in terms of communication and other resources like memory and power. [jhui] I'd argue the opposite. In many cases, maintaining only bi- directional links can be cheaper than trying to maintain a set of disjoint directional links, communicating directional links between nodes, and generating a workable topology over them. >> - Section 5.3: I suggest renaming this attribute to Path Delay to >> better describe the latency of delivering a message across the >> entire path. Propagation Delay has already caused some confusion on >> this list and, as traditionally defined, is fairly insignificant >> compared to the other causes of delivery delays. >> >> ===> Here, we try to specify all link attributes as metrics. Of >> course, path delay impacts more on routing decision, but >> calculating it costs very high and we need to evaluate all possible >> paths with global view. I think extending to paths from links is >> not a good idea when considering routing metrics especially in LLNs >> due to high costs. [jhui] All I was saying is that I usually view propagation delay as the time it takes for the signal to traverse the medium across a single link. Giving it a different name will help remove some of the confusion on this list. -- Jonathan Hui >> - Section 5.4: As mentioned with 5.2, bi-directional links are not >> just important for routing, but to enable the use of link >> mechanisms such as link-layer acknowledgements. Are there others >> that feel strongly against preferring routes that support >> relatively good bi-directional communication? >> ===> I do agree that there are good reasons to consider bi- >> directionality. But we also need to consider costs to maintain it >> and try to find the best way to figure out and keep it. >> >> - Section 6: I think it's best to leave the first paragraph in and >> strike the remaining two. It's useful to give the warning, but we >> don't have to explain how to address it in this draft. >> >> ===> I think there is no harm to keep those sentences, which give >> more information. But we need to revise them, though. >> >> Jonathan Hui >> >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 08:24:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF0A28C0E5; Mon, 10 Nov 2008 08:24:31 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA01528C0E4 for ; Mon, 10 Nov 2008 08:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDMIlZuTi-pA for ; Mon, 10 Nov 2008 08:24:29 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 0884C28C0E5 for ; Mon, 10 Nov 2008 08:24:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F1C1EAF8B4; Mon, 10 Nov 2008 08:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoRBn3VMq0pT; Mon, 10 Nov 2008 08:24:25 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 1B464AF882; Mon, 10 Nov 2008 08:24:25 -0800 (PST) Message-Id: <10501106-EB19-486A-9A19-7EA5A9B1FEA7@archrock.com> From: Jonathan Hui To: "Schoofs, Anthony" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 08:24:24 -0800 References: X-Mailer: Apple Mail (2.929.2) Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Anthony, This implies that nodes will have sufficient capabilities to maintain = a list for an arbitrary number of neighbors. In some cases, a node may = have hundreds of neighbors and the routing protocol should not fail = simply because it cannot maintain state for a significant portion of = them. -- Jonathan Hui On Nov 5, 2008, at 1:12 AM, Schoofs, Anthony wrote: > In 6lowPAN networks, a node may be able to calculate its degree = > thanks to 6lowpan Neighbor Discovery mechanisms. > LowPAN routers could know how many nodes are surrounding them via = > Router Solicitations and Router Registration messages they receive = > from neighboring nodes. > Because these mechanisms are repeated periodically, LowPAN Routers = > may be able to maintain a =93fresh=94 node degree without having to = > generate extra packets. > > Best regards, > Anthony > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = > Of JP Vasseur > Sent: Tuesday 4 November 2008 9:31 > To: MiJeom Kim; Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Hi, > > > On 11/3/08 10:19 AM, "MiJeom Kim" wrote: > Hi, Phil, > > You are absolutely right. I missed link asymmetry. > However, in link state protocols, nodes keep the list of neighbors. > > JP> In link state each node knows the entire topology, thus the set = > of neighbors. > > Even in distance vector protocols, I think there is a high chance = > for nodes to be aware of their neighbors as time goes. As you = > mentioned, for constrained nodes, it might be overhead to keep the = > neighbor list. But, I don't think it is very resource consuming to = > find out the neighbors unless considering very dynamic networks. > > JP> This is clearly a tradeoff between protocol overhead to keep = > track of a list of neighbors (potentially not a negligible amount of = > data) compared to what it brings to routing. If the motivation is to = > compute alternate routes, there are other technique and the node = > degree is not sufficient to compute diverse path anyway so this = > would at best be used as a heuristic. > > My main concern is whether we need the node degree as a LLN routing = > metric and if we do, how we manipulate it. As the document says, it = > is questionable whether high node degrees are preferable or not. The = > decision requires too many factors need to be considered. = > Consequently, it's challenging to make use of node degree as a metric. > > JP> Right. > > So .. I guess that we have a WG consensus not to use it. > > Anybody with a different opinion ? > > Thanks. > > JP. > > Thanks. > Mijeom. > > On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis = > wrote: > > On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: > > 4.6: Is the intention that a node calculates its degree? This is = > very difficult (some might say impossible under any realistic = > network scenario). First, it requires O(n^2) communication. The = > observation that routing protocols might want to change decisions = > based on density makes sense, but by stating it is a metric that = > implies nodes calculate it. > =3D=3D=3D> > I think a node can figure out its degree by overhearing. So as time = > goes, it can get the number of neighbors more precisely. > > That would be true if degree were defined as the number of neighbors = > a node can hear. However, it's defined as > > Node degree is the number of neighbors that can receive a message > from the node directly. > > Unless you assume asymmetric links do not exist, this requires each = > node to report the set of nodes from which it hears messages, so = > those nodes can calculate their degree. It also requires a node to = > maintain state linear in the number of its neighbors, which is = > problematic. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > The information contained in this message may be confidential and = > legally protected under applicable law. The message is intended = > solely for the addressee(s). If you are not the intended recipient, = > you are hereby notified that any use, forwarding, dissemination, or = > reproduction of this message is strictly prohibited and may be = > unlawful. If you are not the intended recipient, please contact the = > sender by return e-mail and destroy all copies of the original = > message. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 08:43:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9EB3A6A3D; Mon, 10 Nov 2008 08:43:49 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987A53A6A27 for ; Mon, 10 Nov 2008 08:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.991 X-Spam-Level: X-Spam-Status: No, score=-4.991 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSNTzyKUrl87 for ; Mon, 10 Nov 2008 08:43:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E80413A686C for ; Mon, 10 Nov 2008 08:43:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,575,1220227200"; d="scan'208,217";a="27354714" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2008 16:43:41 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAAGhfJr027004; Mon, 10 Nov 2008 11:43:41 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAAGhfY7002164; Mon, 10 Nov 2008 16:43:41 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 11:43:41 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Nov 2008 16:42:43 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 10 Nov 2008 17:42:39 +0100 From: JP Vasseur To: Anders Brandt , , Kris Pister Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclASyGEMTjY8xFnTCOz0i/kZ1ya1QC/GiSwAALzaeI= In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429312@zensys17.zensys.local> Mime-version: 1.0 X-OriginalArrivalTime: 10 Nov 2008 16:43:41.0118 (UTC) FILETIME=[7CC19DE0:01C94353] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=36177; t=1226335421; x=1227199421; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Anders=20Brandt=20,=20,=0A=20=20=20=20=20=20=20=20Kris=20Pister=20

; bh=P9HxhfjkGMNfy4WlHcNu70epc6oo3bPDLq8GIcK+HjM=; b=pyDwBU/9pu1/YF4dA/aUN6xVIM9mV+WIyh6OhuOcYF4vCY19ewTC9WI7/B hhw1CwuxNO3m69J2CEcoMPh6tt+k33P4kTDejUFT6DixsUbJySpqJ8HijxgK 7SVV2I7Xoy; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1845595333==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1845595333== Content-type: multipart/alternative; boundary="B_3309183760_20831855" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3309183760_20831855 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks for the feed-back, it is an identified metric (node attribute). Cheers, JP. On 11/10/08 4:55 PM, "Anders Brandt" wrote: > Jerry touches a point I forgot to mention in relation to Kris' previous > postings. > > I fully support the idea of preferred routers running on battery. > We definitely also see this application in the home control domain. > >> > ...let's say I have a battery powered repeater installed in a sparse >> portion of the mesh. This device has no other meaning in >> > life but to route messages. Rerouting around this device saves the energy >> on a device that has no reason to save energy. >> > Also, remember this repeater was strategically placed to 'fill-in' the >> mesh. > > In order to attract interest from the routing protocol, such a node should be > able to signal "mains powered" or even better: > "I have plenty of battery". > Obviously, it should lower that indication to normal "battery-powered" if > running close to low; ending with "battery low". > br. Anders > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jerald.P.Martocci@jci.com > Sent: 6. november 2008 21:04 > To: Kris Pister > Cc: ROLL WG; Ted.Humpal@jci.com > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > Kris, > > I'm getting your point, to a point... > > First off, in the Commercial Building market, all routering devices will be > lines powered and hence the routing protocol need not concern itself with > power starved routers. You must be vying for some sort of synchronous network > where the routers power up on a very short duty cycle. Our radios typically > require 10000x more energy (~27ma) when powered up and transmitting or > receiving than asleep (2uA). You would blow out the joules of any reasonably > sized battery quite quickly if the receiver needed to be on for extended > periods on the off-chance that a message needed to be routered through it. > > As for the routing protocol needing a priori knowledge of the battery status > of a device to determine selected paths, I still don't see this as a network > routing parameter. The node that becomes energy starved simply needs to stop > forwarding routed messages. The transport will quickly notice that messages > are not reaching their destination and advertise for a new path to which our > energy starved device won't respond. A more graceful approach would be for > the energy starved node to simply tell the source node that it is temporarily > out of the routering business. This functionality needs to be in place anyway > since even in normal operation, an existing path might get blocked. > > By advertising remaining energy throughout the network and making systemic > routing choices based on available energy seems like a nice thing to do and > would tend to balance the total available energy across the mesh. However, > the network also must understand the application running on the node to make > the choice. For example, let's say I have a battery powered repeater > installed in a sparse portion of the mesh. This device has no other meaning > in life but to route messages. Rerouting around this device saves the energy > on a device that has no reason to save energy. Also, remember this repeater > was strategically placed to 'fill-in' the mesh. By taking it out of the mesh > routes, all the other nodes will need to use up more of their available energy > to make up for this missing node. > > Conversely, (kind of!!!) let's say I have a sensor that needs to report status > temporally. Even if I stop routing, I still need to awaken to do my own task > on a periodic basis. In many cases I can synchronize my application with the > duty cycle of the network. Now I can continue to perform both jobs without > reducing energy any more than I would performing my one required job. > > My point being that it is important to understand the application requirements > as well as battery status to make judicious routing decisions. Why not let > each device decide no its own if it can save power by taking itself out of the > routing paths. The mesh would then just re-form as needed around the devices. > > Jerry > > > > > > Kris Pister 11/05/2008 10:08 PM > To > Jerald.P.Martocci@jci.com > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > > > Jerry - I'm not trying to get the IETF decide the threshold for any > flags. My point is that a single bit flag is virtually useless for > making intelligent routing decisions, regardless of what threshold value > you choose for it. > > You say that remaining energy is not a function of time, and yet the > units you use to describe where you set the threshold are "months" :) > Somehow we have to make the same kind of translations between Joules and > months, and for networks where the routers are battery powered, this IS > a routing issue. > > Here's why: ignoring energy in routing decisions, protocol X creates > networks that have a distribution of lifetimes varying, for example, > from three to fifteen years. Protocol Y, using energy in its routing > decisions, builds networks that have the same mean lifetime, but a > distribution that is much tighter - from 9 to 12 years. Which one would > you rather buy? One where you start replacing batteries after 3 years, > or one were you replace them all at 9 years? > > ksjp > > Jerald.P.Martocci@jci.com wrote: >> > >> > Why is the IETF trying to establish when the energy flag needs to be >> > set for low battery? This is an application issue. >> > >> > Remaining energy is not a function of time, it's a function of >> > remaining energy. In our current wireless products, we have a >> > comparator that will shut the sensor down at a given voltage level. >> > We have actually calculated the number of joules required per >> > transaction and have back calculated the voltage level at which point >> > we will issue a low-battery alarm. We set the voltage level to alarm >> > about 3 months before the device shuts down, giving the customer 3 >> > months to change the battery. This is for a device that transmits >> > once a minute for about 3 msecs. The battery status is included >> > (1-bit). with every transaction. Two alkaline 'c' cells will last >> > about 10 years, but due to shelf life, we specify 5 year battery life. >> > >> > From my viewpoint all battery powered wireless devices need to >> > transmit their battery status. For interoperability purposes, this >> > should be dictated. However, this is not a protocol issue, much less >> > a routing issue. This should be something done by the implementers or >> > specified at the alliance level (e.g. IPSO). >> > >> > Jerry >> > >> > >> > >> > >> > >> > *Kris Pister * >> > Sent by: roll-bounces@ietf.org >> > >> > 11/04/2008 06:06 PM >> > >> > >> > To >> > JP Vasseur >> > cc >> > ROLL WG >> > Subject >> > Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Well, we both agree that there will be load imbalance and differential >> > rate of energy consumption, >> > and we both agree that oscillations will be bad. I think that we may >> > have a different picture of the >> > frequency of those oscillations, though. I think that most/all of the >> > systems described in the >> > requirements docs have battery lifetime requirements measured in >> > years. This implies a minimum >> > update rate of, oh, something like monthly. Sending a few tens of >> > bytes of data describing >> > energy and power state on a daily basis is both far more frequent than >> > we need, and unlikely >> > to cause *wasteful* oscillations. If there is some route bouncing >> > with a one day or week period, maybe >> > that's actually optimal. It's certainly not expensive. >> > >> > I'm still very curious as to where you think that we should set the >> > "low energy" flag level. Based on the two scenarios that I presented, >> > I don't see that single-bit flags have much value. As you pointed out >> > in your response, the traffic will not be balanced. Either I set the >> > flag near midpoint, and it doesn't help much, or I set well below >> > midpoint, and it doesn't help very much. >> > >> > I can imagine scenarios in which it works great. Unfortunately, >> > working well 50% of the time doesn't do us much good. We don't have >> > to handle every situation, but we have to at least deal with common >> > problems that come up in real networks. >> > >> > ksjp >> > >> > JP Vasseur wrote: >> > Hi Kris, >> > >> > >> > On 11/4/08 6:28 AM, "Kris Pister" __ >> > wrote: >> > >> > >> > JP - I'd like to understand more about your flags. >> > If I have a network in which I expect that all motes last for 7 years, >> > where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 >> > years)? At 5% (ideally 3 months)? >> > In the first case, for roughly half of my network lifetime, all of my >> > network will have set the "I'm low on energy" flag, and I will have no >> > useful information with which to make routing decisions. >> > In the second case, I have almost no useful information until it's too >> > late - one year into operation and several of the busiest motes are >> > almost dead, while a mote with a much bigger battery still has almost >> > all of it's charge. So in this case the information shows up too late >> > to be useful. >> > I'm sure that's not the way you see it. What am I missing? >> > >> > >> > >> > See it as a trade-off between frequent accurate updates (=> requiring >> > energy, risk of routing oscillations, ...) and no information at all. >> > If you >> > make the assumption of uniform energy consumption, then flags are always >> > useless (so does more up to date data). On the other hand if you see >> > the use >> > of such flags as safeguard mechanisms, this could be useful to start >> > rerouting the traffic around nodes running out of battery. Suppose >> > that the >> > traffic is not equally balanced in the network, you may end up with nodes >> > consuming battery at a much higher rates than others, in which case the >> > flags may be useful, with no risk of oscillation. >> > >> > Thoughts ? >> > >> > Cheers, >> > >> > JP. >> > >> > >> > ksjp >> > >> > JP Vasseur wrote: >> > >> > Hi Miguel, >> > >> > >> > On 10/31/08 12:24 PM, "Miguel Sanchez" __ >> > wrote: >> > >> > >> > >> > Hi JP, >> > >> > >> > >> > On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur __ >> > wrote: >> > >> > >> > Hi Kris, >> > >> > >> > On 10/30/08 5:33 PM, "Kris Pister" __ >> > wrote: >> > >> > I agree with Miguel that we need a standard way of energy reporting, and I >> > agree with JP that it's hard to do. >> > Part of the challenge is that energy sources and storage vary so much. We >> > have: >> > * line power - great if you can get it! >> > * battery storage >> > - this is time varying. The available energy in a battery is a >> > strong >> > function of the temperature and the usage profile. So a battery powered >> > mote may correctly calculate five years of lifetime in summer, and then >> > that >> > winter under the exact same load conditions it may correctly calculate a >> > lifetime of ten years. The same mote with the same battery may have >> > better >> > performance in summer at higher loads. >> > >> > JP> and usage profile may also change. >> > >> > * capacitive storage >> > * energy scavenging >> > - this is time varying, and tough to bound (usefully >> > >> > JP> this is why I'm questioning the usefulness of knowing the remaining >> > energy expressed in Joules or other metrics. Knowing this value will not >> > tell you anything as to whether you should or should not use that node >> > when >> > computing the path. Another metric may be the remaining estimated lifetime >> > >> > >> > I disagree. >> > >> > At least if remaining energy is infinitum (mains powered) tells you >> > something. >> > >> > OTOH, if limited, depending on other properties of the nodes (like >> > where it gets its energy from) it is also useful for making routing >> > decisions too. >> > >> > >> > OK let's try to step back. I'm proposing a flag-based mechanism to >> > avoid the >> > use of a node should this node run out of energy. The decision to set the >> > flag is made by the node (no specified) according to many parameters >> > (estimated like time, ... Etc). Some nodes having more power may make >> > use of >> > complex models. >> > >> > If you advertise your remaining power in Joules, how would you expect the >> > nodes to change their routing decisions since they have no idea of whether >> > you are running low in energy (it highly depends on what the node >> > does, the >> > external conditions, ... Etc) ? >> > >> > Thanks. >> > >> > JP. >> > >> > >> > >> > but still, is the node capable (without consuming too much energy) of >> > gathering historical data etc ... to provide an accurate value hoping that >> > other criterion such as usage profile or temperature as you pointed out >> > will >> > not change ? >> > >> > All of this makes energy/power/lifetime reporting painful, yet I can not >> > picture a successful routing protocol that doesn't somehow take these >> > factors into account. >> > >> > >> > >> > Kind regards, >> > >> > Miguel >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Roll mailing list >> > Roll@ietf.org >> > https://www.ietf.org/mailman/listinfo/roll >> > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3309183760_20831855 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Roll] ROLL Routing Metrics - WF feed-back needed Thanks for the feed-back, it is an identified metric (node attribute).

Cheers,

JP.


On 11/10/08 4:55 PM, "Anders Brandt" <abr@zen-sys.com> wrote:

Jerry touches a point I forgot to mention in relation t= o Kris' previous postings.

I fully support the idea of preferred routers running on battery.
We definitely also see this application in the home control domain.
> ...let's say I have a battery powered repeat= er installed in a sparse portion of the mesh.  This device has no other= meaning in
> life but to route messages. Rerouting around this device saves the ene= rgy on a device that has no reason to save energy.
>  Also, remember this repeater was strategically placed to 'fill-i= n' the mesh.
In order to attract interes= t from the routing protocol, such a node should be able to signal "main= s powered" or even better:
"I have plenty of battery".
Obviously, it should lower that indication to normal "battery-powered&= quot; if running close to low; ending with "battery low".
br. Anders

 
From: roll-bounces@= ietf.org [mailto:roll-bounces@iet= f.org] On Behalf Of Jerald.P.= Martocci@jci.com
Sent: 6. november 2008 21:04
To: Kris Pister
Cc: ROLL WG; Ted.Humpal@jci.com
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed


Kris,

I'm getting your point, to a point...

First off, in the Commercial Building market, all routering devices will be= lines powered and hence the routing protocol need not concern itself with p= ower starved routers.  You must be vying for some sort of synchronous n= etwork where the routers power up on a very short duty cycle.  Our radi= os typically require 10000x more energy (~27ma) when powered up and transmit= ting or receiving  than asleep (2uA).  You would blow out the joul= es of any reasonably sized battery quite quickly if the receiver needed to b= e on for extended periods on the off-chance that a message needed to be rout= ered through it.   

As for the routing protocol needing a priori knowledge of the battery statu= s of a device to determine selected paths, I still don't see this as a netwo= rk routing parameter.  The node that becomes energy starved simply need= s to stop forwarding routed messages.   The transport will quickly= notice that messages are not reaching their destination and advertise for a= new path to which our energy starved device won't respond.  A more gra= ceful approach would be for the energy starved node to simply tell the sourc= e node that it is temporarily out of the routering business.  This func= tionality needs to be in place anyway since even in normal operation, an exi= sting path might get blocked.

By advertising remaining energy throughout the network and making systemic = routing choices based on available energy seems like a nice thing to do and = would tend to balance the total available energy across the mesh.  Howe= ver, the network also must understand the application running on the node to= make the choice.  For example, let's say I have a battery powered repe= ater installed in a sparse portion of the mesh.  This device has no oth= er meaning in life but to route messages.  Rerouting around this device= saves the energy on a device that has no reason to save energy.  Also,= remember this repeater was strategically placed to 'fill-in' the mesh. &nbs= p;By taking it out of the mesh routes, all the other nodes will need to use = up more of their available energy to make up for this missing node.

Conversely, (kind of!!!) let's say I have a sensor that needs to report sta= tus temporally.  Even if I stop routing, I still need to awaken to do m= y own task on a periodic basis.  In many cases I can synchronize my app= lication with the duty cycle of the network.  Now I can continue to per= form both jobs without reducing energy any more than I would performing my o= ne required job.

My point being that it is important to understand the application requireme= nts as well as battery status to make judicious routing decisions.  Why= not let each device decide no its own if it can save power by taking itself= out of the routing paths.  The mesh would then just re-form as needed = around the devices.

Jerry




  
 Kris Pister  <pister@eecs.berkeley.edu>  11/05/2008 10:08 PM  &= nbsp;  

 To

Jerald.P.Martocci@jci.com  

 cc

ROLL WG  <roll@ietf.org>  

 Subject

Re: [Roll] ROLL Routin= g Metrics -  WF feed-back needed
   
  



Jerry - I'm not trying to get the IETF decide the= threshold for any
flags.  My point is that a single bit flag is virtually useless for making intelligent routing decisions, regardless of what threshold value you choose for it.

You say that remaining energy is not a function of time, and yet the
units you use to describe where you set the threshold are "months"= ; :)  
Somehow we have to make the same kind of translations between Joules and months, and for networks where the routers are battery powered, this IS a routing issue.

Here's why: ignoring energy in routing decisions, protocol X creates
networks that have a distribution of lifetimes varying, for example,
from three to fifteen years.  Protocol Y, using energy in its routing =
decisions, builds networks that have the same mean lifetime, but a
distribution that is much tighter - from 9 to 12 years.  Which one wou= ld
you rather buy?  One where you start replacing batteries after 3 years= ,
or one were you replace them all at 9 years?

ksjp

Jerald.P.Martocci@jci.com wrote: >
> Why is the IETF trying to establish when the energy flag needs to be <= BR> > set for low battery?  This is an application issue.  
>
> Remaining energy is not a function of time, it's a function of
> remaining energy.  In our current wireless products, we have a > comparator that will shut the sensor down at a given voltage level. >  We have actually calculated the number of joules required per > transaction and have back calculated the voltage level at which point =
> we will issue a low-battery alarm.  We set the voltage level to a= larm
> about 3 months before the device shuts down, giving the customer 3 > months to change the battery.  This is for a device that transmit= s
> once a minute for about 3 msecs.  The battery status is included =
> (1-bit). with every transaction.  Two alkaline  'c' cells wi= ll last
> about 10 years, but due to shelf life, we specify 5 year battery life.=
>
> From my viewpoint all battery powered wireless devices need to
> transmit their battery status.  For interoperability purposes, th= is
> should be dictated.  However, this is not a protocol issue, much = less
> a routing issue.  This should be something done by the implemente= rs or
> specified at the alliance level (e.g. IPSO).
>
> Jerry
>
>
>
>
>
> *Kris Pister <pister@eecs.b= erkeley.edu>*
> Sent by: roll-bounces@ietf.org
>
> 11/04/2008 06:06 PM
>
>            &nbs= p;     
> To
>            &nbs= p;     JP Vasseur <= jvasseur@cisco.com>
> cc
>            &nbs= p;     ROLL WG <roll@iet= f.org>
> Subject
>            &nbs= p;     Re: [Roll] ROLL Routing Metrics - WF feed-ba= ck needed
>
>
>
>            &nbs= p;     
>
>
>
>
>
> Well, we both agree that there will be load imbalance and differential=
> rate of energy consumption,
> and we both agree that oscillations will be bad.  I think that we= may
> have a different picture of the
> frequency of those oscillations, though.  I think that most/all o= f the
> systems described in the
> requirements docs have battery lifetime requirements measured in
> years.  This implies a minimum
> update rate of, oh, something like monthly.  Sending a few tens o= f
> bytes of data describing
> energy and power state on a daily basis is both far more frequent than=
> we need, and unlikely
> to cause *wasteful* oscillations.  If there is some route bouncin= g
> with a one day or week period, maybe
> that's actually optimal.  It's certainly not expensive.
>
> I'm still very curious as to where you think that we should set the > "low energy" flag level.  Based on the two scenarios th= at I presented,
> I don't see that single-bit flags have much value.  As you pointe= d out
> in your response, the traffic will not be balanced.  Either I set= the
> flag near midpoint, and it doesn't help much, or I set well below
> midpoint, and it doesn't help very much.
>
> I can imagine scenarios in which it works great.  Unfortunately, =
> working well 50% of the time doesn't do us much good.  We don't h= ave
> to handle every situation, but we have to at least deal with common > problems that come up in real networks.
>
> ksjp
>
> JP Vasseur wrote:
> Hi Kris,
>
>
> On 11/4/08 6:28 AM, "Kris Pister" _<pister@eecs.berkeley.edu>_
> <mailto:pister@eecs.berke= ley.edu> wrote:
>
>  
> JP - I'd like to understand more about your flags.
> If I have a network in which I expect that all motes last for 7 years,=
> where do I set the "I'm low on energy" flag?  At 50% (i= deally 3.5
> years)?  At 5% (ideally 3 months)?
> In the first case, for roughly half of my network lifetime, all of my<= BR> > network will have set the "I'm low on energy" flag, and I wi= ll have no
> useful information with which to make routing decisions.
> In the second case, I have almost no useful information until it's too=
> late - one year into operation and several of the busiest motes are > almost dead, while a mote with a much bigger battery still has almost<= BR> > all of it's charge.  So in this case the information shows up too= late
> to be useful.
> I'm sure that's not the way you see it.  What am I missing?
>
>    
>
> See it as a trade-off between frequent accurate updates (=3D> requiri= ng
> energy, risk of routing oscillations, ...) and no information at all. =
> If you
> make the assumption of uniform energy consumption, then flags are alwa= ys
> useless (so does more up to date data). On the other hand if you see <= BR> > the use
> of such flags as safeguard mechanisms, this could be useful to start > rerouting the traffic around nodes running out of battery. Suppose > that the
> traffic is not equally balanced in the network, you may end up with no= des
> consuming battery at a much higher rates than others, in which case th= e
> flags may be useful, with no risk of oscillation.
>
> Thoughts ?
>
> Cheers,
>
> JP.
>
>  
> ksjp
>
> JP Vasseur wrote:
>    
> Hi Miguel,
>
>
> On 10/31/08 12:24 PM, "Miguel Sanchez" _<misan@disca.upv.es>_
> <mailto:misan@disca.upv.es&= gt; wrote:
>
>  
>      
> Hi JP,
>
>
>
> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur _<jvasseur@cisco.com>_
> <mailto:jvasseur@cisco.com&= gt; wrote:
>    
>        
> Hi Kris,
>
>
> On 10/30/08 5:33 PM, "Kris Pister" _<pister@eecs.berkeley.edu>_
> <mailto:pister@eecs.berke= ley.edu> wrote:
>
> I agree with Miguel that we need a standard way of energy reporting, a= nd I
> agree with JP that it's hard to do.
> Part of the challenge is that energy sources and storage vary so much.= We
> have:
> * line power - great if you can get it!
> * battery storage
>      - this is time varying.  The availa= ble energy in a battery is a
> strong
> function of the temperature and the usage profile.  So a battery = powered
> mote may correctly calculate five years of lifetime in summer, and the= n
> that
> winter under the exact same load conditions it may correctly calculate= a
> lifetime of ten years.  The same mote with the same battery may h= ave
> better
> performance in summer at higher loads.
>
> JP> and usage profile may also change.
>
> * capacitive storage
> * energy scavenging
>      - this is time varying, and tough to bou= nd (usefully
>
> JP> this is why I'm questioning the usefulness of knowing the remai= ning
> energy expressed in Joules or other metrics. Knowing this value will n= ot
> tell you anything as to whether you should or should not use that node=
> when
> computing the path. Another metric may be the remaining estimated life= time
>      
>          
> I disagree.
>
> At least if remaining energy is infinitum (mains powered) tells you > something.
>
> OTOH, if limited, depending on other properties of the nodes (like
> where it gets its energy from) it is also useful for making routing > decisions too.
>    
>        
> OK let's try to step back. I'm proposing a flag-based mechanism to > avoid the
> use of a node should this node run out of energy. The decision to set = the
> flag is made by the node (no specified) according to many parameters > (estimated like time, ... Etc). Some nodes having more power may make =
> use of
> complex models.
>
> If you advertise your remaining power in Joules, how would you expect = the
> nodes to change their routing decisions since they have no idea of whe= ther
> you are running low in energy (it highly depends on what the node
> does, the
> external conditions, ... Etc) ?
>
> Thanks.
>
> JP.
>
>  
>      
> but still, is the node capable (without consuming too much energy) of<= BR> > gathering historical data etc ... to provide an accurate value hoping = that
> other criterion such as usage profile or temperature as you pointed ou= t
> will
> not change ?
>
> All of this makes energy/power/lifetime reporting painful, yet I can n= ot
> picture a successful routing protocol that doesn't somehow take these<= BR> > factors into account.
>
>      
>          
> Kind regards,
>
> Miguel
>    
>        
>  
>      
>
>  _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.= org/mailman/listinfo/roll
>


___________= ____________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
--B_3309183760_20831855-- --===============1845595333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1845595333==-- From roll-bounces@ietf.org Mon Nov 10 08:44:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9207B3A6A3D; Mon, 10 Nov 2008 08:44:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC283A69EB for ; Mon, 10 Nov 2008 08:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jondUSzc49q7 for ; Mon, 10 Nov 2008 08:44:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DD1113A6A3D for ; Mon, 10 Nov 2008 08:44:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,575,1220227200"; d="scan'208";a="192019996" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2008 16:44:43 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAAGihbk022915; Mon, 10 Nov 2008 08:44:43 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAAGigpq019380; Mon, 10 Nov 2008 16:44:42 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 11:44:41 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Nov 2008 16:44:22 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 10 Nov 2008 17:44:20 +0100 From: JP Vasseur To: Jonathan Hui , "Schoofs, Anthony" Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclDU5PuvJGYkdesd029bQ7PPzePhg== In-Reply-To: <10501106-EB19-486A-9A19-7EA5A9B1FEA7@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 10 Nov 2008 16:44:41.0919 (UTC) FILETIME=[A0FF1CF0:01C94353] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5185; t=1226335483; x=1227199483; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=egjETtglJSMeNFRFHwfZTGWMctz2ZMY/x1d8CcGYrZE=; b=QoyuTKXNd1VgrDdNX/RsYG4LIJlvDT8pMY11oBukCSDLbXmx1Yq5FRNg3+ QGRSg0TltD9597fdIt/h+iraV4xTSdxsGXt+p04pdMdrA8f9d9peWCOw0Qjc LEGJ3xSsp9; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Furthermore, it is not yet obvious that such metric will be so useful from a routing standpoint ... On 11/10/08 5:24 PM, "Jonathan Hui" wrote: > = > Hi Anthony, > = > This implies that nodes will have sufficient capabilities to maintain > a list for an arbitrary number of neighbors. In some cases, a node may > have hundreds of neighbors and the routing protocol should not fail > simply because it cannot maintain state for a significant portion of > them. > = > -- > Jonathan Hui > = > = > = > On Nov 5, 2008, at 1:12 AM, Schoofs, Anthony wrote: > = >> In 6lowPAN networks, a node may be able to calculate its degree >> thanks to 6lowpan Neighbor Discovery mechanisms. >> LowPAN routers could know how many nodes are surrounding them via >> Router Solicitations and Router Registration messages they receive >> from neighboring nodes. >> Because these mechanisms are repeated periodically, LowPAN Routers >> may be able to maintain a =B3fresh=B2 node degree without having to >> generate extra packets. >> = >> Best regards, >> Anthony >> = >> = >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of JP Vasseur >> Sent: Tuesday 4 November 2008 9:31 >> To: MiJeom Kim; Philip Levis >> Cc: ROLL WG >> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> = >> Hi, >> = >> = >> On 11/3/08 10:19 AM, "MiJeom Kim" wrote: >> Hi, Phil, >> = >> You are absolutely right. I missed link asymmetry. >> However, in link state protocols, nodes keep the list of neighbors. >> = >> JP> In link state each node knows the entire topology, thus the set >> of neighbors. >> = >> Even in distance vector protocols, I think there is a high chance >> for nodes to be aware of their neighbors as time goes. As you >> mentioned, for constrained nodes, it might be overhead to keep the >> neighbor list. But, I don't think it is very resource consuming to >> find out the neighbors unless considering very dynamic networks. >> = >> JP> This is clearly a tradeoff between protocol overhead to keep >> track of a list of neighbors (potentially not a negligible amount of >> data) compared to what it brings to routing. If the motivation is to >> compute alternate routes, there are other technique and the node >> degree is not sufficient to compute diverse path anyway so this >> would at best be used as a heuristic. >> = >> My main concern is whether we need the node degree as a LLN routing >> metric and if we do, how we manipulate it. As the document says, it >> is questionable whether high node degrees are preferable or not. The >> decision requires too many factors need to be considered. >> Consequently, it's challenging to make use of node degree as a metric. >> = >> JP> Right. >> = >> So .. I guess that we have a WG consensus not to use it. >> = >> Anybody with a different opinion ? >> = >> Thanks. >> = >> JP. >> = >> Thanks. >> Mijeom. >> = >> On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis >> wrote: >> = >> On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: >> = >> 4.6: Is the intention that a node calculates its degree? This is >> very difficult (some might say impossible under any realistic >> network scenario). First, it requires O(n^2) communication. The >> observation that routing protocols might want to change decisions >> based on density makes sense, but by stating it is a metric that >> implies nodes calculate it. >> =3D=3D=3D> >> I think a node can figure out its degree by overhearing. So as time >> goes, it can get the number of neighbors more precisely. >> = >> That would be true if degree were defined as the number of neighbors >> a node can hear. However, it's defined as >> = >> Node degree is the number of neighbors that can receive a message >> from the node directly. >> = >> Unless you assume asymmetric links do not exist, this requires each >> node to report the set of nodes from which it hears messages, so >> those nodes can calculate their degree. It also requires a node to >> maintain state linear in the number of its neighbors, which is >> problematic. >> = >> Phil >> = >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> = >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended >> solely for the addressee(s). If you are not the intended recipient, >> you are hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 08:47:06 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B523A6874; Mon, 10 Nov 2008 08:47:06 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73453A6874 for ; Mon, 10 Nov 2008 08:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmCWDk9Sb3r0 for ; Mon, 10 Nov 2008 08:47:04 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id E38973A67A1 for ; Mon, 10 Nov 2008 08:47:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 1C590AF8CA; Mon, 10 Nov 2008 08:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCtTpplbdHq9; Mon, 10 Nov 2008 08:47:01 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id 12DE2AF882; Mon, 10 Nov 2008 08:47:01 -0800 (PST) Message-Id: <179BEE15-66AD-4A65-A449-2F292BF8A049@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 08:46:59 -0800 References: X-Mailer: Apple Mail (2.929.2) Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Completely agree. We also haven't yet come up with a clear definition = of node degree. -- Jonathan Hui On Nov 10, 2008, at 8:44 AM, JP Vasseur wrote: > Furthermore, it is not yet obvious that such metric will be so = > useful from a > routing standpoint ... > > > On 11/10/08 5:24 PM, "Jonathan Hui" wrote: > >> >> Hi Anthony, >> >> This implies that nodes will have sufficient capabilities to maintain >> a list for an arbitrary number of neighbors. In some cases, a node = >> may >> have hundreds of neighbors and the routing protocol should not fail >> simply because it cannot maintain state for a significant portion of >> them. >> >> -- >> Jonathan Hui >> >> >> >> On Nov 5, 2008, at 1:12 AM, Schoofs, Anthony wrote: >> >>> In 6lowPAN networks, a node may be able to calculate its degree >>> thanks to 6lowpan Neighbor Discovery mechanisms. >>> LowPAN routers could know how many nodes are surrounding them via >>> Router Solicitations and Router Registration messages they receive >>> from neighboring nodes. >>> Because these mechanisms are repeated periodically, LowPAN Routers >>> may be able to maintain a =93fresh=94 node degree without having to >>> generate extra packets. >>> >>> Best regards, >>> Anthony >>> >>> >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of JP Vasseur >>> Sent: Tuesday 4 November 2008 9:31 >>> To: MiJeom Kim; Philip Levis >>> Cc: ROLL WG >>> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >>> >>> Hi, >>> >>> >>> On 11/3/08 10:19 AM, "MiJeom Kim" wrote: >>> Hi, Phil, >>> >>> You are absolutely right. I missed link asymmetry. >>> However, in link state protocols, nodes keep the list of neighbors. >>> >>> JP> In link state each node knows the entire topology, thus the set >>> of neighbors. >>> >>> Even in distance vector protocols, I think there is a high chance >>> for nodes to be aware of their neighbors as time goes. As you >>> mentioned, for constrained nodes, it might be overhead to keep the >>> neighbor list. But, I don't think it is very resource consuming to >>> find out the neighbors unless considering very dynamic networks. >>> >>> JP> This is clearly a tradeoff between protocol overhead to keep >>> track of a list of neighbors (potentially not a negligible amount of >>> data) compared to what it brings to routing. If the motivation is to >>> compute alternate routes, there are other technique and the node >>> degree is not sufficient to compute diverse path anyway so this >>> would at best be used as a heuristic. >>> >>> My main concern is whether we need the node degree as a LLN routing >>> metric and if we do, how we manipulate it. As the document says, it >>> is questionable whether high node degrees are preferable or not. The >>> decision requires too many factors need to be considered. >>> Consequently, it's challenging to make use of node degree as a = >>> metric. >>> >>> JP> Right. >>> >>> So .. I guess that we have a WG consensus not to use it. >>> >>> Anybody with a different opinion ? >>> >>> Thanks. >>> >>> JP. >>> >>> Thanks. >>> Mijeom. >>> >>> On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis >>> wrote: >>> >>> On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: >>> >>> 4.6: Is the intention that a node calculates its degree? This is >>> very difficult (some might say impossible under any realistic >>> network scenario). First, it requires O(n^2) communication. The >>> observation that routing protocols might want to change decisions >>> based on density makes sense, but by stating it is a metric that >>> implies nodes calculate it. >>> =3D=3D=3D> >>> I think a node can figure out its degree by overhearing. So as time >>> goes, it can get the number of neighbors more precisely. >>> >>> That would be true if degree were defined as the number of neighbors >>> a node can hear. However, it's defined as >>> >>> Node degree is the number of neighbors that can receive a message >>> from the node directly. >>> >>> Unless you assume asymmetric links do not exist, this requires each >>> node to report the set of nodes from which it hears messages, so >>> those nodes can calculate their degree. It also requires a node to >>> maintain state linear in the number of its neighbors, which is >>> problematic. >>> >>> Phil >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> The information contained in this message may be confidential and >>> legally protected under applicable law. The message is intended >>> solely for the addressee(s). If you are not the intended recipient, >>> you are hereby notified that any use, forwarding, dissemination, or >>> reproduction of this message is strictly prohibited and may be >>> unlawful. If you are not the intended recipient, please contact the >>> sender by return e-mail and destroy all copies of the original >>> message. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 08:47:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F213A28C0CE; Mon, 10 Nov 2008 08:47:51 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550C73A6A3D for ; Mon, 10 Nov 2008 08:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTb9Mymd13NP for ; Mon, 10 Nov 2008 08:47:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 207623A69EB for ; Mon, 10 Nov 2008 08:47:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,575,1220227200"; d="scan'208";a="102685410" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2008 16:47:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAAGlk0n024151; Mon, 10 Nov 2008 08:47:46 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAAGlcfD023679; Mon, 10 Nov 2008 16:47:46 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 11:47:44 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Nov 2008 16:46:46 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 10 Nov 2008 17:46:42 +0100 From: JP Vasseur To: Jonathan Hui , MiJeom Kim Message-ID: Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclDU+iSzfsRR8VfkE2jYyprnr53cg== In-Reply-To: <2853C451-5AD6-4650-B5E2-AB3DFB1D0494@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 10 Nov 2008 16:47:44.0216 (UTC) FILETIME=[0DA76D80:01C94354] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7766; t=1226335666; x=1227199666; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=sBswk/7jb532zPCSvLkn439o37CfNQUwwI1OSfRkb3k=; b=GF0aa4byaHz4c3i6Rc2c20DccO7YZAXaTbBvZ66tgKKXB/m6MdzdfFNzVG h2UpJlxnfOL0wl4cX7Rp2msZyeRmVxJKkxF6KduO9RIKkQJ21M3CCatJk22c c1vL6T+lCI; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan, I'd like to go back to one specific since you referred to it twice: why would you want bidirectional link metrics ? Where IP routing is inherently asymmetrical. Thanks. JP. On 11/10/08 5:21 PM, "Jonathan Hui" wrote: > > Hi MiJeom, see below: > > On Nov 3, 2008, at 11:46 PM, MiJeom Kim wrote: > >> Hi, Jonathan, really appriciate your valuable comments. Please see >> below. >> >> On Tue, Nov 4, 2008 at 3:02 AM, Jonathan Hui >> wrote: >>> >>> - Section 4.3 and 4.4: I understand that these are important >>> metrics with more traditional (higher power) link technologies, but >>> I think the description does not sufficiently characterize the >>> challenges in LLNs. In general, most of the high-order bits in >>> these metrics will be due to communication delays at the link layer >>> (scheduled communication as well as conservative backoffs can cause >>> communication delays on the order of seconds and even 10s of >>> seconds). This can easily dwarf all other delays caused by >>> processing times. For the networks I'm used to dealing with, I'd >>> argue that communication latency is much more significant than node >>> workload. >>> >>> ==> I totally agree on what you said here. However, L2 delay >>> depends on MAC protocols and it's very fluctuating by time. If >>> there is high contention for a given channel, it takes more time to >>> send a packet with contention based protocols. In contention-free >>> protocols, L2 delay is more predictable and consistent. Due to the >>> all dependency, I do not think it is possible to make L2 delay as a >>> routing metric. > > [jhui] There are significant constant factors that we can consider > when considering L2 delay - duty cycle and phase. Both of which > determine the *minimum* latency. Both of which can be on the order of > seconds or more. > >>> - Section 4.5: I'm not convinced that the Data Aggregation >>> attribute is best to have within the network layer. Data >>> aggregation is application specific. The great thing about route- >>> over is that it exposes all of the physical connectivity above IP, >>> and doing so supports the construction of higher-layer structures >>> (i.e. overlays) that can support things like in-network processing. >>> I personally feel that data aggregation is best left for higher >>> layers. >>> >>> ==> I agree that data aggregation is application or traffic >>> dependent. Let's hear other's opinion. > > [jhui] In some cases, unicast routing is not always the best way to > aggregate information between nodes that are within physical proximity. > >>> - Section 4.6: I share the same concern with Phil. While even DV >>> protocols maintain neighbors, the strict resource constraints of >>> LLNs often restrict nodes to maintaining state about a *subset* of >>> their neighbors. I do believe that maintaining a node's degree in >>> terms of bi-directional links will not fit within the resource >>> constraints of typical LLNs in the general case. However, degree is >>> a useful metric to have, if we can both define and evaluate it >>> properly. >>> >>> ==> As I mentioned already, we need to reach consensus on the way >>> to evaluate node degree. Higher degree would be preferable, but >>> does this apply for all situations? Also, we need to evaluate trade- >>> off between cost and benefit of using node degree as a metric. > > [jhui] Yes. What is degree, really? All nodes that can communicate to > A? All nodes that A can communicate to? Both? These definitions have > subtle differences on the use of a degree metric and that is dependent > on the L2 capabilities below. > >>> - Section 4.7: Agreeing with what was mentioned earlier on the >>> list, the distinction between Dynamicity (4.7) and Link >>> Reliability (5.2) is not obvious to me. In some sense, we have only >>> marginal control over network topology and node behaviors - they >>> are often driven by surrounding environmental factors. >>> >>> ==> we can't control the dynamicity or reliability. We just need to >>> monitor and estimate them to construct a better path by avoiding >>> highly dynamic and unreliable nodes. We need to have clear >>> definitions for them and methods to measure them, which is >>> challenging. > > [jhui] That's exactly my point. The way we monitor dynamicity and > reliability may be very similar... > >>> - Section 5.1: I think the metric we really want here is >>> throughput. Bandwidth is only one of many factor that affects the >>> link's throughput. >>> >>> ==> I agree. Actual average data rate can be one factor to affect >>> the throughput. Do you have other factors in your mind? > > [jhui] The L2 protocol is the largest factor in what throughput you > can expect on that link. > >>> - Section 5.2: Just a personal opinion here, but I strongly believe >>> that bi-directional link success rates (PRR) will be much more >>> useful than directional success rates. Due to the lossy nature of >>> LLNs, I expect most, if not all, LLNs to utilize link-layer >>> acknowledgments. Furthermore, enforcing metrics to be bi- >>> directional have significant simplification advantages with respect >>> to routing. >>> >>> ===> I do agree, but maintaining bi-directional metrics costs more >>> in terms of communication and other resources like memory and power. > > [jhui] I'd argue the opposite. In many cases, maintaining only bi- > directional links can be cheaper than trying to maintain a set of > disjoint directional links, communicating directional links between > nodes, and generating a workable topology over them. > >>> - Section 5.3: I suggest renaming this attribute to Path Delay to >>> better describe the latency of delivering a message across the >>> entire path. Propagation Delay has already caused some confusion on >>> this list and, as traditionally defined, is fairly insignificant >>> compared to the other causes of delivery delays. >>> >>> ===> Here, we try to specify all link attributes as metrics. Of >>> course, path delay impacts more on routing decision, but >>> calculating it costs very high and we need to evaluate all possible >>> paths with global view. I think extending to paths from links is >>> not a good idea when considering routing metrics especially in LLNs >>> due to high costs. > > [jhui] All I was saying is that I usually view propagation delay as > the time it takes for the signal to traverse the medium across a > single link. Giving it a different name will help remove some of the > confusion on this list. > > -- > Jonathan Hui > >>> - Section 5.4: As mentioned with 5.2, bi-directional links are not >>> just important for routing, but to enable the use of link >>> mechanisms such as link-layer acknowledgements. Are there others >>> that feel strongly against preferring routes that support >>> relatively good bi-directional communication? >>> ===> I do agree that there are good reasons to consider bi- >>> directionality. But we also need to consider costs to maintain it >>> and try to find the best way to figure out and keep it. >>> >>> - Section 6: I think it's best to leave the first paragraph in and >>> strike the remaining two. It's useful to give the warning, but we >>> don't have to explain how to address it in this draft. >>> >>> ===> I think there is no harm to keep those sentences, which give >>> more information. But we need to revise them, though. >>> >>> Jonathan Hui >>> >>> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 09:05:17 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3BF28C0E3; Mon, 10 Nov 2008 09:05:17 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6D628C0E3 for ; Mon, 10 Nov 2008 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ7-i+scoadD for ; Mon, 10 Nov 2008 09:05:15 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 5255F3A6A42 for ; Mon, 10 Nov 2008 09:05:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2B64BAF8CA; Mon, 10 Nov 2008 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gByxIsFLsdHg; Mon, 10 Nov 2008 09:05:11 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id E52BDAF882; Mon, 10 Nov 2008 09:05:10 -0800 (PST) Message-Id: <4619A6F3-5A55-4C90-B33B-45A12C4F0943@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 09:05:09 -0800 References: X-Mailer: Apple Mail (2.929.2) Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, The root of this, of course, is the limited capabilities of the nodes. In general, nodes in LLNs can only maintain state for a (potentially small) subset of nodes. The first question is which subset? How do we ensure that the joint topology represented by the subset of nodes each node picked provides reachability to all nodes? There are ways to ensure this, but they are often costly (require floods, elections, etc.). This may seem counterintuitive, but maintaining directional link metrics can actually be more costly than maintaining bi-directional ones. The directional case implies that the receiver is maintaining state about the transmitter. First, for that information to be useful, the receiver must communicate that information to whoever is performing the routing computations and ultimately that metric/ decision based on that metric has to go back to the transmitter. Second, it limits the in-degree of the node (nodes that can route through the receiver). Instead, if the link provides bi-directional success rates using its synchronous acknowledgements, the transmitter can maintain state for whatever number of routes it maintains and there is no routing limit on the in-degree of the receiver since the state is distributed among the transmitters. Finally, for many of the link technologies that we use today, forwarding relies on the use of synchronous acks for hop-by-hop recovery. In that case, some measure of bi-directionality is required and already provided by the link. Restricting use to bi-directional links for any arbitrary link is not what I really meant. As you pointed out, there are many cases where use of directional links is useful (if not required). I was just picking an extreme point to see how people would react :-). BTW, having bi-directional link metrics does not mean routes have to be chosen in a symmetric way. -- Jonathan Hui On Nov 10, 2008, at 8:46 AM, JP Vasseur wrote: > Hi Jonathan, > > I'd like to go back to one specific since you referred to it twice: > why > would you want bidirectional link metrics ? Where IP routing is > inherently > asymmetrical. > > Thanks. > > JP. > > > On 11/10/08 5:21 PM, "Jonathan Hui" wrote: > >> >> Hi MiJeom, see below: >> >> On Nov 3, 2008, at 11:46 PM, MiJeom Kim wrote: >> >>> Hi, Jonathan, really appriciate your valuable comments. Please see >>> below. >>> >>> On Tue, Nov 4, 2008 at 3:02 AM, Jonathan Hui >>> wrote: >>>> >>>> - Section 4.3 and 4.4: I understand that these are important >>>> metrics with more traditional (higher power) link technologies, but >>>> I think the description does not sufficiently characterize the >>>> challenges in LLNs. In general, most of the high-order bits in >>>> these metrics will be due to communication delays at the link layer >>>> (scheduled communication as well as conservative backoffs can cause >>>> communication delays on the order of seconds and even 10s of >>>> seconds). This can easily dwarf all other delays caused by >>>> processing times. For the networks I'm used to dealing with, I'd >>>> argue that communication latency is much more significant than node >>>> workload. >>>> >>>> ==> I totally agree on what you said here. However, L2 delay >>>> depends on MAC protocols and it's very fluctuating by time. If >>>> there is high contention for a given channel, it takes more time to >>>> send a packet with contention based protocols. In contention-free >>>> protocols, L2 delay is more predictable and consistent. Due to the >>>> all dependency, I do not think it is possible to make L2 delay as a >>>> routing metric. >> >> [jhui] There are significant constant factors that we can consider >> when considering L2 delay - duty cycle and phase. Both of which >> determine the *minimum* latency. Both of which can be on the order of >> seconds or more. >> >>>> - Section 4.5: I'm not convinced that the Data Aggregation >>>> attribute is best to have within the network layer. Data >>>> aggregation is application specific. The great thing about route- >>>> over is that it exposes all of the physical connectivity above IP, >>>> and doing so supports the construction of higher-layer structures >>>> (i.e. overlays) that can support things like in-network processing. >>>> I personally feel that data aggregation is best left for higher >>>> layers. >>>> >>>> ==> I agree that data aggregation is application or traffic >>>> dependent. Let's hear other's opinion. >> >> [jhui] In some cases, unicast routing is not always the best way to >> aggregate information between nodes that are within physical >> proximity. >> >>>> - Section 4.6: I share the same concern with Phil. While even DV >>>> protocols maintain neighbors, the strict resource constraints of >>>> LLNs often restrict nodes to maintaining state about a *subset* of >>>> their neighbors. I do believe that maintaining a node's degree in >>>> terms of bi-directional links will not fit within the resource >>>> constraints of typical LLNs in the general case. However, degree is >>>> a useful metric to have, if we can both define and evaluate it >>>> properly. >>>> >>>> ==> As I mentioned already, we need to reach consensus on the way >>>> to evaluate node degree. Higher degree would be preferable, but >>>> does this apply for all situations? Also, we need to evaluate >>>> trade- >>>> off between cost and benefit of using node degree as a metric. >> >> [jhui] Yes. What is degree, really? All nodes that can communicate to >> A? All nodes that A can communicate to? Both? These definitions have >> subtle differences on the use of a degree metric and that is >> dependent >> on the L2 capabilities below. >> >>>> - Section 4.7: Agreeing with what was mentioned earlier on the >>>> list, the distinction between Dynamicity (4.7) and Link >>>> Reliability (5.2) is not obvious to me. In some sense, we have only >>>> marginal control over network topology and node behaviors - they >>>> are often driven by surrounding environmental factors. >>>> >>>> ==> we can't control the dynamicity or reliability. We just need to >>>> monitor and estimate them to construct a better path by avoiding >>>> highly dynamic and unreliable nodes. We need to have clear >>>> definitions for them and methods to measure them, which is >>>> challenging. >> >> [jhui] That's exactly my point. The way we monitor dynamicity and >> reliability may be very similar... >> >>>> - Section 5.1: I think the metric we really want here is >>>> throughput. Bandwidth is only one of many factor that affects the >>>> link's throughput. >>>> >>>> ==> I agree. Actual average data rate can be one factor to affect >>>> the throughput. Do you have other factors in your mind? >> >> [jhui] The L2 protocol is the largest factor in what throughput you >> can expect on that link. >> >>>> - Section 5.2: Just a personal opinion here, but I strongly believe >>>> that bi-directional link success rates (PRR) will be much more >>>> useful than directional success rates. Due to the lossy nature of >>>> LLNs, I expect most, if not all, LLNs to utilize link-layer >>>> acknowledgments. Furthermore, enforcing metrics to be bi- >>>> directional have significant simplification advantages with respect >>>> to routing. >>>> >>>> ===> I do agree, but maintaining bi-directional metrics costs more >>>> in terms of communication and other resources like memory and >>>> power. >> >> [jhui] I'd argue the opposite. In many cases, maintaining only bi- >> directional links can be cheaper than trying to maintain a set of >> disjoint directional links, communicating directional links between >> nodes, and generating a workable topology over them. >> >>>> - Section 5.3: I suggest renaming this attribute to Path Delay to >>>> better describe the latency of delivering a message across the >>>> entire path. Propagation Delay has already caused some confusion on >>>> this list and, as traditionally defined, is fairly insignificant >>>> compared to the other causes of delivery delays. >>>> >>>> ===> Here, we try to specify all link attributes as metrics. Of >>>> course, path delay impacts more on routing decision, but >>>> calculating it costs very high and we need to evaluate all possible >>>> paths with global view. I think extending to paths from links is >>>> not a good idea when considering routing metrics especially in LLNs >>>> due to high costs. >> >> [jhui] All I was saying is that I usually view propagation delay as >> the time it takes for the signal to traverse the medium across a >> single link. Giving it a different name will help remove some of the >> confusion on this list. >> >> -- >> Jonathan Hui >> >>>> - Section 5.4: As mentioned with 5.2, bi-directional links are not >>>> just important for routing, but to enable the use of link >>>> mechanisms such as link-layer acknowledgements. Are there others >>>> that feel strongly against preferring routes that support >>>> relatively good bi-directional communication? >>>> ===> I do agree that there are good reasons to consider bi- >>>> directionality. But we also need to consider costs to maintain it >>>> and try to find the best way to figure out and keep it. >>>> >>>> - Section 6: I think it's best to leave the first paragraph in and >>>> strike the remaining two. It's useful to give the warning, but we >>>> don't have to explain how to address it in this draft. >>>> >>>> ===> I think there is no harm to keep those sentences, which give >>>> more information. But we need to revise them, though. >>>> >>>> Jonathan Hui >>>> >>>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 09:10:05 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C88D28C0EF; Mon, 10 Nov 2008 09:10:05 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5CC3A6A27 for ; Mon, 10 Nov 2008 09:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.492 X-Spam-Level: X-Spam-Status: No, score=-5.492 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK31Z3KpY3mL for ; Mon, 10 Nov 2008 09:10:03 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CD9A428C0EF for ; Mon, 10 Nov 2008 09:10:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,576,1220227200"; d="scan'208,217";a="27358007" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2008 17:09:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAAH9x1H022618; Mon, 10 Nov 2008 12:09:59 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAAH9xKP020675; Mon, 10 Nov 2008 17:09:59 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 12:09:58 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Nov 2008 17:09:52 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Mon, 10 Nov 2008 18:09:51 +0100 From: JP Vasseur To: Message-ID: Thread-Topic: ROLL Updated Milestones Thread-Index: AclDVyR6TT1ANaHgy0ylNraI2gzG8Q== Mime-version: 1.0 X-OriginalArrivalTime: 10 Nov 2008 17:09:58.0925 (UTC) FILETIME=[2933DBD0:01C94357] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3058; t=1226336999; x=1227200999; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20ROLL=20Updated=20Milestones |Sender:=20 |To:=20; bh=cDGtHa+u1vQTNQ/nkAsjffD3hbKiEKw1zKcWiuFfFGQ=; b=NQ9EUsnr3afzQfmNfYXl77bgajT4yn1sDiM9FVoisW9Q9CsAkDPbxg+FJ9 UXDcBLfIMo9Y0ypERziCqfosLuMlSrn8yYl/3PUXavq0ROCbGiQ2JptPkNT3 /wWyzwXrS2; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] ROLL Updated Milestones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0802501503==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0802501503== Content-type: multipart/alternative; boundary="B_3309185392_20900215" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3309185392_20900215 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Goals and Milestones: Jul 2008 Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Jul 2008 Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Jul 2008 Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. Nov 2008 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. Apr 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. Jun 2009 Recharter or close. --B_3309185392_20900215 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable ROLL Updated Milestones Goals and Milestones:

Jul 2008          Submit Routing requirements= for Industrial applications to the IESG to be considered as an Informationa= l RFC.
Jul 2008          Submit Routing requirements= for Connected Home networks applications to the IESG to be considered as an= Informational RFC.
Jul 2008          Submit Routing requirements= for Building applications to the IESG to be considered as an Informational = RFC.
Done          Submit Routin= g requirements for Urban networks applications to the IESG to be considered = as an Informational RFC.
Nov 2008          Submit Routing metrics = for LLNs document to the IESG to be considered as a Proposed Standard.
Feb 2009          Submit Protocol Survey to t= he IESG to be considered as an Informational RFC.
Apr 2009          Submit Security Framework t= o the IESG to be considered as an Informational RFC
May 2009          Submit the Routing for LLNs= Architecture document to the IESG as an Informational RFC.
Jun 2009          Recharter or close.<= /FONT> --B_3309185392_20900215-- --===============0802501503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0802501503==-- From roll-bounces@ietf.org Mon Nov 10 10:16:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0389A3A6A6C; Mon, 10 Nov 2008 10:16:12 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C635828C146 for ; Mon, 10 Nov 2008 10:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGbtA3AAvoYZ for ; Mon, 10 Nov 2008 10:16:09 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 3FEC73A68BA for ; Mon, 10 Nov 2008 10:16:09 -0800 (PST) Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 10 Nov 2008 19:16:08 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Mon, 10 Nov 2008 19:16:04 +0100 From: "Schoofs, Anthony" To: Jonathan Hui Date: Mon, 10 Nov 2008 19:16:03 +0100 Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclDUM3z1HfUMmTbQiqsY+pctm/EtQADQsip Message-ID: References: , <10501106-EB19-486A-9A19-7EA5A9B1FEA7@archrock.com> In-Reply-To: <10501106-EB19-486A-9A19-7EA5A9B1FEA7@archrock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Philip@core3.amsl.com, ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan, The draft currently says that "Node degree is the number of neighbors that = can receive a message from the node directly. " If this implies that you need to maintain a list for an arbitrary number of= neighbors , then it is indeed not favorable. If you are only interested in the number of neighbours, there may be some w= ays to deliver that number without having to maintain a list of neighbors. = For example (just a try), adding +1 to a Node degree variable for each new = ICMP message (RS or RR) received by a LowPAN router and have the variable r= eseted periodically (depending on the RS and RR refresh periods of the LowP= AN hosts) could give a node degree to LowPAN routers. Besides, I also agree that we shoud consider first whether we need the Node= degree metric. Best regards, Anthony ________________________________________ From: Jonathan Hui [jhui@archrock.com] Sent: Monday, November 10, 2008 5:24 PM To: Schoofs, Anthony Cc: JP Vasseur; MiJeom Kim; Philip Levis; ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Hi Anthony, This implies that nodes will have sufficient capabilities to maintain a list for an arbitrary number of neighbors. In some cases, a node may have hundreds of neighbors and the routing protocol should not fail simply because it cannot maintain state for a significant portion of them. -- Jonathan Hui On Nov 5, 2008, at 1:12 AM, Schoofs, Anthony wrote: > In 6lowPAN networks, a node may be able to calculate its degree > thanks to 6lowpan Neighbor Discovery mechanisms. > LowPAN routers could know how many nodes are surrounding them via > Router Solicitations and Router Registration messages they receive > from neighboring nodes. > Because these mechanisms are repeated periodically, LowPAN Routers > may be able to maintain a =93fresh=94 node degree without having to > generate extra packets. > > Best regards, > Anthony > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Tuesday 4 November 2008 9:31 > To: MiJeom Kim; Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Hi, > > > On 11/3/08 10:19 AM, "MiJeom Kim" wrote: > Hi, Phil, > > You are absolutely right. I missed link asymmetry. > However, in link state protocols, nodes keep the list of neighbors. > > JP> In link state each node knows the entire topology, thus the set > of neighbors. > > Even in distance vector protocols, I think there is a high chance > for nodes to be aware of their neighbors as time goes. As you > mentioned, for constrained nodes, it might be overhead to keep the > neighbor list. But, I don't think it is very resource consuming to > find out the neighbors unless considering very dynamic networks. > > JP> This is clearly a tradeoff between protocol overhead to keep > track of a list of neighbors (potentially not a negligible amount of > data) compared to what it brings to routing. If the motivation is to > compute alternate routes, there are other technique and the node > degree is not sufficient to compute diverse path anyway so this > would at best be used as a heuristic. > > My main concern is whether we need the node degree as a LLN routing > metric and if we do, how we manipulate it. As the document says, it > is questionable whether high node degrees are preferable or not. The > decision requires too many factors need to be considered. > Consequently, it's challenging to make use of node degree as a metric. > > JP> Right. > > So .. I guess that we have a WG consensus not to use it. > > Anybody with a different opinion ? > > Thanks. > > JP. > > Thanks. > Mijeom. > > On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis > wrote: > > On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: > > 4.6: Is the intention that a node calculates its degree? This is > very difficult (some might say impossible under any realistic > network scenario). First, it requires O(n^2) communication. The > observation that routing protocols might want to change decisions > based on density makes sense, but by stating it is a metric that > implies nodes calculate it. > =3D=3D=3D> > I think a node can figure out its degree by overhearing. So as time > goes, it can get the number of neighbors more precisely. > > That would be true if degree were defined as the number of neighbors > a node can hear. However, it's defined as > > Node degree is the number of neighbors that can receive a message > from the node directly. > > Unless you assume asymmetric links do not exist, this requires each > node to report the set of nodes from which it hears messages, so > those nodes can calculate their degree. It also requires a node to > maintain state linear in the number of its neighbors, which is > problematic. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended > solely for the addressee(s). If you are not the intended recipient, > you are hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 10:33:46 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2853A685C; Mon, 10 Nov 2008 10:33:46 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB0C3A685C for ; Mon, 10 Nov 2008 10:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNODBMizxWJf for ; Mon, 10 Nov 2008 10:33:43 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 9CD603A67FD for ; Mon, 10 Nov 2008 10:33:43 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A0279AF8D6; Mon, 10 Nov 2008 10:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzutkPINeSk2; Mon, 10 Nov 2008 10:33:40 -0800 (PST) Received: from [192.168.7.78] (69-12-164-140.sfo.archrock.com [69.12.164.140]) by mail.sf.archrock.com (Postfix) with ESMTP id DCCA3AF879; Mon, 10 Nov 2008 10:33:39 -0800 (PST) Message-Id: From: Jonathan Hui To: "Schoofs, Anthony" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 10:33:39 -0800 References: , <10501106-EB19-486A-9A19-7EA5A9B1FEA7@archrock.com> X-Mailer: Apple Mail (2.929.2) Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Anthony, On Nov 10, 2008, at 10:16 AM, Schoofs, Anthony wrote: > If this implies that you need to maintain a list for an arbitrary = > number of neighbors , then it is indeed not favorable. > If you are only interested in the number of neighbours, there may be = > some ways to deliver that number without having to maintain a list = > of neighbors. For example (just a try), adding +1 to a Node degree = > variable for each new ICMP message (RS or RR) received by a LowPAN = > router and have the variable reseted periodically (depending on the = > RS and RR refresh periods of the LowPAN hosts) could give a node = > degree to LowPAN routers. This requires nodes to broadcast beacons with a fixed period and = implies that beacon periods are not adaptive to local conditions - not = good characteristics if we're trying to develop an energy efficient = protocol. -- Jonathan Hui > Besides, I also agree that we shoud consider first whether we need = > the Node degree metric. > > Best regards, > Anthony > > ________________________________________ > From: Jonathan Hui [jhui@archrock.com] > Sent: Monday, November 10, 2008 5:24 PM > To: Schoofs, Anthony > Cc: JP Vasseur; MiJeom Kim; Philip Levis; ROLL WG > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Hi Anthony, > > This implies that nodes will have sufficient capabilities to maintain > a list for an arbitrary number of neighbors. In some cases, a node may > have hundreds of neighbors and the routing protocol should not fail > simply because it cannot maintain state for a significant portion of > them. > > -- > Jonathan Hui > > > > On Nov 5, 2008, at 1:12 AM, Schoofs, Anthony wrote: > >> In 6lowPAN networks, a node may be able to calculate its degree >> thanks to 6lowpan Neighbor Discovery mechanisms. >> LowPAN routers could know how many nodes are surrounding them via >> Router Solicitations and Router Registration messages they receive >> from neighboring nodes. >> Because these mechanisms are repeated periodically, LowPAN Routers >> may be able to maintain a =93fresh=94 node degree without having to >> generate extra packets. >> >> Best regards, >> Anthony >> >> >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of JP Vasseur >> Sent: Tuesday 4 November 2008 9:31 >> To: MiJeom Kim; Philip Levis >> Cc: ROLL WG >> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> >> Hi, >> >> >> On 11/3/08 10:19 AM, "MiJeom Kim" wrote: >> Hi, Phil, >> >> You are absolutely right. I missed link asymmetry. >> However, in link state protocols, nodes keep the list of neighbors. >> >> JP> In link state each node knows the entire topology, thus the set >> of neighbors. >> >> Even in distance vector protocols, I think there is a high chance >> for nodes to be aware of their neighbors as time goes. As you >> mentioned, for constrained nodes, it might be overhead to keep the >> neighbor list. But, I don't think it is very resource consuming to >> find out the neighbors unless considering very dynamic networks. >> >> JP> This is clearly a tradeoff between protocol overhead to keep >> track of a list of neighbors (potentially not a negligible amount of >> data) compared to what it brings to routing. If the motivation is to >> compute alternate routes, there are other technique and the node >> degree is not sufficient to compute diverse path anyway so this >> would at best be used as a heuristic. >> >> My main concern is whether we need the node degree as a LLN routing >> metric and if we do, how we manipulate it. As the document says, it >> is questionable whether high node degrees are preferable or not. The >> decision requires too many factors need to be considered. >> Consequently, it's challenging to make use of node degree as a = >> metric. >> >> JP> Right. >> >> So .. I guess that we have a WG consensus not to use it. >> >> Anybody with a different opinion ? >> >> Thanks. >> >> JP. >> >> Thanks. >> Mijeom. >> >> On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis >> wrote: >> >> On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: >> >> 4.6: Is the intention that a node calculates its degree? This is >> very difficult (some might say impossible under any realistic >> network scenario). First, it requires O(n^2) communication. The >> observation that routing protocols might want to change decisions >> based on density makes sense, but by stating it is a metric that >> implies nodes calculate it. >> =3D=3D=3D> >> I think a node can figure out its degree by overhearing. So as time >> goes, it can get the number of neighbors more precisely. >> >> That would be true if degree were defined as the number of neighbors >> a node can hear. However, it's defined as >> >> Node degree is the number of neighbors that can receive a message >> from the node directly. >> >> Unless you assume asymmetric links do not exist, this requires each >> node to report the set of nodes from which it hears messages, so >> those nodes can calculate their degree. It also requires a node to >> maintain state linear in the number of its neighbors, which is >> problematic. >> >> Phil >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended >> solely for the addressee(s). If you are not the intended recipient, >> you are hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > The information contained in this message may be confidential and = > legally protected under applicable law. The message is intended = > solely for the addressee(s). If you are not the intended recipient, = > you are hereby notified that any use, forwarding, dissemination, or = > reproduction of this message is strictly prohibited and may be = > unlawful. If you are not the intended recipient, please contact the = > sender by return e-mail and destroy all copies of the original = > message. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 13:28:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EAA3A6838; Mon, 10 Nov 2008 13:28:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB433A6838 for ; Mon, 10 Nov 2008 13:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj17qzvJOmzO for ; Mon, 10 Nov 2008 13:28:06 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A9B5C3A67A1 for ; Mon, 10 Nov 2008 13:28:06 -0800 (PST) Received: from dnab422089.stanford.edu ([171.66.32.137]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1KzeIj-0002fR-54; Mon, 10 Nov 2008 13:28:01 -0800 Message-Id: <4B2811A9-8941-4FC0-9AA9-5A17A137CC45@cs.stanford.edu> From: Philip Levis To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429312@zensys17.zensys.local> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 13:27:58 -0800 References: <49126E8D.5030306@eecs.berkeley.edu> <6D9687E95918C04A8B30A7D6DA805A3E01429312@zensys17.zensys.local> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 7e839a9fe5d3c1ffc6f045e071031982 Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote: > Jerry touches a point I forgot to mention in relation to Kris' > previous postings. > > I fully support the idea of preferred routers running on battery. > We definitely also see this application in the home control domain. > > > ...let's say I have a battery powered repeater installed in a > sparse portion of the mesh. This device has no other meaning in > > life but to route messages. Rerouting around this device saves the > energy on a device that has no reason to save energy. > > Also, remember this repeater was strategically placed to 'fill- > in' the mesh. > > In order to attract interest from the routing protocol, such a node > should be able to signal "mains powered" or even better: > "I have plenty of battery". > Obviously, it should lower that indication to normal "battery- > powered" if running close to low; ending with "battery low". > br. Anders > > > I'm confused by this line of logic. Whether a node advertises itself as having lots of energy is less important than the available energy along a route. I.e., if the next hop, node A, has lots of energy but its next hop, node B, is very limited, the fact that A has lots of energy is not particularly useful. So far, this discussion has assumed that a node must communicate a lot of factors to other nodes, so they can apply their own algorithms to decide which next hop to take. The issue here is that it assumes the optimization criteria are the same; even though the router-to-be wants to save energy, the sender wants to optimize latency and so ignores energy constraints. Another approach is that each node applies its own algorithm to determine its willingness/cost, which other nodes then take into account. That is, nodes advertise how good a router they think they are, and senders take this into consideration. Otherwise, especially in a distributed and dynamic system, senders can be making decisions based on out-of-date information which is hard to detect inconsistencies on without expensive periodic state exchanges. E.g., one simple way to articulate energy, rather than "I have X" is "How expensive I consider sending a packet." This takes into consideration a lot more useful information, and is much more flexible to compute and consider. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 14:48:27 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DB23A6A68; Mon, 10 Nov 2008 14:48:27 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E7B3A6A68 for ; Mon, 10 Nov 2008 14:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7whYer3yoy7 for ; Mon, 10 Nov 2008 14:48:25 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 69E823A676A for ; Mon, 10 Nov 2008 14:48:25 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAAMmEjC013579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2008 14:48:15 -0800 (PST) Message-ID: <4918BB25.7030405@eecs.berkeley.edu> Date: Mon, 10 Nov 2008 14:52:21 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Philip Levis References: <49126E8D.5030306@eecs.berkeley.edu> <6D9687E95918C04A8B30A7D6DA805A3E01429312@zensys17.zensys.local> <4B2811A9-8941-4FC0-9AA9-5A17A137CC45@cs.stanford.edu> In-Reply-To: <4B2811A9-8941-4FC0-9AA9-5A17A137CC45@cs.stanford.edu> Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Phil - I agree that the optimal routes are going to be a function of the state of all of the nodes along each route, not just one node advertising that it's fat and happy. I don't think that I agree that we're assuming that a node must communicate a lot of factors to other nodes. I can imagine something like AODV, but where each node adds its own hop cost. Depending on shared network parameters, each node might add e.g. 1/(remaining lifetime) to the total route cost, or it might add it's link-latency to the route cost. I'm not advocating something AODV-like, just pointing out that we don't necessarily need to be propagating a lot of state information around the network, and potentially complicated (and platform dependent) local computations can still be done without the global algorithm needing to know the details. ksjp Philip Levis wrote: > > On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote: > >> Jerry touches a point I forgot to mention in relation to Kris' >> previous postings. >> >> I fully support the idea of preferred routers running on battery. >> We definitely also see this application in the home control domain. >> >> > ...let's say I have a battery powered repeater installed in a >> sparse portion of the mesh. This device has no other meaning in >> > life but to route messages. Rerouting around this device saves the >> energy on a device that has no reason to save energy. >> > Also, remember this repeater was strategically placed to 'fill-in' >> the mesh. >> >> In order to attract interest from the routing protocol, such a node >> should be able to signal "mains powered" or even better: >> "I have plenty of battery". >> Obviously, it should lower that indication to normal >> "battery-powered" if running close to low; ending with "battery low". >> br. Anders >> >> >> > > I'm confused by this line of logic. Whether a node advertises itself > as having lots of energy is less important than the available energy > along a route. I.e., if the next hop, node A, has lots of energy but > its next hop, node B, is very limited, the fact that A has lots of > energy is not particularly useful. > > So far, this discussion has assumed that a node must communicate a lot > of factors to other nodes, so they can apply their own algorithms to > decide which next hop to take. The issue here is that it assumes the > optimization criteria are the same; even though the router-to-be wants > to save energy, the sender wants to optimize latency and so ignores > energy constraints. Another approach is that each node applies its own > algorithm to determine its willingness/cost, which other nodes then > take into account. That is, nodes advertise how good a router they > think they are, and senders take this into consideration. Otherwise, > especially in a distributed and dynamic system, senders can be making > decisions based on out-of-date information which is hard to detect > inconsistencies on without expensive periodic state exchanges. > > E.g., one simple way to articulate energy, rather than "I have X" is > "How expensive I consider sending a packet." This takes into > consideration a lot more useful information, and is much more flexible > to compute and consider. > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 15:04:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A563A6AC5; Mon, 10 Nov 2008 15:04:33 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9917C3A6AC7 for ; Mon, 10 Nov 2008 15:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Laud4CmLz2DL for ; Mon, 10 Nov 2008 15:04:31 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 9BE2A3A6AC5 for ; Mon, 10 Nov 2008 15:04:31 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAAN4ONK013973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2008 15:04:26 -0800 (PST) Message-ID: <4918BEEF.6090704@eecs.berkeley.edu> Date: Mon, 10 Nov 2008 15:08:31 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: MiJeom Kim , ROLL WG References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810300356s1e916d53ye3f3d93cc493838f@mail.gmail.com> <7892795E1A87F04CADFCCF41FADD00FC0683E061@xmb-ams-337.emea.cisco.com> <2544B5EE-0EEB-4FA7-AAC7-AF99FC7B1B0E@cs.stanford.edu> In-Reply-To: Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Mijeom - given that L2 performance can easily vary over three orders of magnitude even with the same radio, I don't understand how we can do a good job of routing without taking L2 delay into account. Your concerns below seem to be that the delay is time varying, and depends on mac protocol. For a given node, of course, the mac protocol is likely to be fixed. Certainly that will be true of a given link. And the rate of change of a parameter like link latency is likely to be low - there will certainly be some "high frequency" (e.g. 1/s) variation, but that's not what a node would report in a routing algorithm. Routing decisions can be made with a filtered version, say with a time constant of hours. Can someone explain how we can do a good job of latency-sensitive routing (an industrial requirement) if we don't take the primary source of latency into account? It seems to me that whether we think that it's hard or not, we have to do it. ksjp MiJeom Kim wrote: > Hi, > > We have had quite a few arguments regarding delay related metrics > through this mailing list. In traditional packet switched networks, > there are four kinds of delays, which are processing delay, queuing > delay, transmission delay and propagation delay. There is one more > delay we make an issue here is L2 delay caused by MAC protocols. The > document classifies the first three delays as node latency, one of > node metrics and propagation delay as a link metric. > > Let's take into consideration one by one. > - Processing delay: it's time for a node to process a packet including > header analysis and error check. I personally prefer to exclude > processing delay from metrics since it is kind of negligible and is > depending on node's computing resource which is specified as a node > metric. > - Queuing delay: it is depending on time and current node workload > (the number of packets arrived earlier), thus I prefer to exclude it, > too. > - Transmission delay: it's time to push the packet to the link and > calculated as packet size/bit rate. It's a function of packet size, > which is hard to make it a metric. We can take bit rate as a factor to > affect link throughput, though. > - Propagation delay: as we already agreed, it's close to light speed > in radio systems and negligible. So I don't think we need this as a > metric. > - L2 delay: as I mentioned before, it's very fluctuating by time and > depending on MAC protocols. Due to the all dependency I don't think > it's a good idea to take L2 delay as a metric. > > To summary, delay related attributes are mostly varying as time and > depending on variables such as packet size and workload. Therefore, I > don't think anything above can be a feasible routing metric. > Otherwise, we need really well designed schemes to take care of all > the variables affecting the delays and to avoid instability, which is > pretty skeptical. > > Always welcome other opinions, > > Thanks, > Mijeom. > > On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis wrote: > >> On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: >> >> >>> Hi Mijeom, >>> >>> I suspect that in many radio systems with operations similar to IEEE 802, >>> the propagation delay you are talking about is almost useless taken >>> separately since the transaction is only complete when an ack is received >>> back that enables a wireless router to free the resources allocated to the >>> frame and go back to sleep. The time between acking a received frame and >>> receiving the ack for that frame being forwarded is the real latency of a >>> node. If we want to sustain a given rate R with a Latency L, we need R*L in >>> buffer space. Considering that memory is often a constrained resource this >>> is something that we need to account for. >>> >> Pascal, >> >> I'm not sure this is really an issue. You're talking about layer 2 acks? >> Generally those are always transmitted within a quite deterministic and tiny >> time interval; furthermore, media access is designed to prevent transmitting >> on top of them (e.g., through 15.4's double channel sense, or 802.11's NAV). >> The idea that a node has to hold onto a packet for a long time waiting for a >> layer 2 ack just isn't a problem, as they are generally synchronous rather >> than asynchronous (do not go through media access). >> >> Phil >> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 15:24:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D2F3A6A38; Mon, 10 Nov 2008 15:24:24 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DC23A6A38 for ; Mon, 10 Nov 2008 15:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI9sK7TXgc0I for ; Mon, 10 Nov 2008 15:24:22 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id A91813A69E6 for ; Mon, 10 Nov 2008 15:24:22 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAANLYV8014349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2008 15:21:36 -0800 (PST) Message-ID: <4918C2F5.5030809@eecs.berkeley.edu> Date: Mon, 10 Nov 2008 15:25:41 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: mischa.dohler@cttc.es References: <20081110093257.28E0210C31D@leo> In-Reply-To: <20081110093257.28E0210C31D@leo> Cc: amine@sensysnetworks.com, 'ROLL WG' , Tod Dykstra Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Mischa - I agree with everything except the second to last sentence. :) I haven't read the urban draft recently, but I tried to convince Thomas to put in the parking monitoring and traffic light applications, since both of those are actually in production already using LLNs (e.g. StreetlineNetworks.com, SensysNetworks.com). In both cases, latency is a real issue. In any case, even meter and meteorological data has latency constraints. There are those who believe that the best way to get below a 0.1% radio duty cycle is to turn all of the radios on for 60 seconds once a day. There was a product on the market for a while that did this with a 15 minute cycle. I disagree with that approach, but it's certainly a LLN MAC that we might see some day, and hopping across networks like that is going to be painful for most applications. ksjp Mischa Dohler wrote: > Hi Mijeom, all, the conclusion on the instability has - if I understood > correctly - always been drawn assuming a fairly heavily loaded network. With > some exceptions, however, our networks will be lightly loaded and > duty-cycled, which means that in most cases the processing + queuing + > transmission delay << L2 delay. Whilst this L2 delay heavily depends on the > MAC, it is not a value which fluctuates strongly (if at all) over time. The > end-to-end delay, will hence more or less be proportional to the number of > hops multiplied by the L2 delay. Therefore, although differently motivated, > I would agree that delay is not really needed. Having said this, in our > urban scenario, delay is not really a design issue - Jerry, Kris and Anders > may have a different opinion here. Regards, Mischa. > > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > MiJeom Kim > Sent: Monday, November 10, 2008 7:07 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Hi, > > We have had quite a few arguments regarding delay related metrics > through this mailing list. In traditional packet switched networks, > there are four kinds of delays, which are processing delay, queuing > delay, transmission delay and propagation delay. There is one more > delay we make an issue here is L2 delay caused by MAC protocols. The > document classifies the first three delays as node latency, one of > node metrics and propagation delay as a link metric. > > Let's take into consideration one by one. > - Processing delay: it's time for a node to process a packet including > header analysis and error check. I personally prefer to exclude > processing delay from metrics since it is kind of negligible and is > depending on node's computing resource which is specified as a node > metric. > - Queuing delay: it is depending on time and current node workload > (the number of packets arrived earlier), thus I prefer to exclude it, > too. > - Transmission delay: it's time to push the packet to the link and > calculated as packet size/bit rate. It's a function of packet size, > which is hard to make it a metric. We can take bit rate as a factor to > affect link throughput, though. > - Propagation delay: as we already agreed, it's close to light speed > in radio systems and negligible. So I don't think we need this as a > metric. > - L2 delay: as I mentioned before, it's very fluctuating by time and > depending on MAC protocols. Due to the all dependency I don't think > it's a good idea to take L2 delay as a metric. > > To summary, delay related attributes are mostly varying as time and > depending on variables such as packet size and workload. Therefore, I > don't think anything above can be a feasible routing metric. > Otherwise, we need really well designed schemes to take care of all > the variables affecting the delays and to avoid instability, which is > pretty skeptical. > > Always welcome other opinions, > > Thanks, > Mijeom. > > On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis wrote: > >> On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: >> >> >>> Hi Mijeom, >>> >>> I suspect that in many radio systems with operations similar to IEEE 802, >>> the propagation delay you are talking about is almost useless taken >>> separately since the transaction is only complete when an ack is received >>> back that enables a wireless router to free the resources allocated to >>> > the > >>> frame and go back to sleep. The time between acking a received frame and >>> receiving the ack for that frame being forwarded is the real latency of a >>> node. If we want to sustain a given rate R with a Latency L, we need R*L >>> > in > >>> buffer space. Considering that memory is often a constrained resource >>> > this > >>> is something that we need to account for. >>> >> Pascal, >> >> I'm not sure this is really an issue. You're talking about layer 2 acks? >> Generally those are always transmitted within a quite deterministic and >> > tiny > >> time interval; furthermore, media access is designed to prevent >> > transmitting > >> on top of them (e.g., through 15.4's double channel sense, or 802.11's >> > NAV). > >> The idea that a node has to hold onto a packet for a long time waiting for >> > a > >> layer 2 ack just isn't a problem, as they are generally synchronous rather >> than asynchronous (do not go through media access). >> >> Phil >> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 15:26:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49C73A6A4E; Mon, 10 Nov 2008 15:26:47 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4761B3A6A4E for ; Mon, 10 Nov 2008 15:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_BACKHAIR_11=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY7ECab7zkcL for ; Mon, 10 Nov 2008 15:26:44 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id D90DC3A69E6 for ; Mon, 10 Nov 2008 15:26:44 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAANQdFS014466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2008 15:26:40 -0800 (PST) Message-ID: <4918C426.8040002@eecs.berkeley.edu> Date: Mon, 10 Nov 2008 15:30:46 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Cc: ROLL WG , Ted.Humpal@jci.com Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Jerry - powered routing infrastructure is great if you can afford it. For applications which can't, then battery powered routers are a must. Whether these use the venerable Low Power Listen approach, or the upstart Time Synchronized Mesh approach, you get sub-second latency and power consumption that is in the tens of uA. You're right that I'm representing the interests of the synchronous network community - that's what industrial automation is using today, with Wireless HART (shipping) and ISA100.11a (in draft). If you only use powered routers, then I agree that the whole energy-reporting thing is of little interest. The requirement for industrial is that we be able to do power-aware and latency-sensitive routing though. ksjp Jerald.P.Martocci@jci.com wrote: > > Kris, > > I'm getting your point, to a point... > > First off, in the Commercial Building market, all routering devices > will be lines powered and hence the routing protocol need not concern > itself with power starved routers. You must be vying for some sort of > synchronous network where the routers power up on a very short duty > cycle. Our radios typically require 10000x more energy (~27ma) when > powered up and transmitting or receiving than asleep (2uA). You > would blow out the joules of any reasonably sized battery quite > quickly if the receiver needed to be on for extended periods on the > off-chance that a message needed to be routered through it. > > As for the routing protocol needing a priori knowledge of the battery > status of a device to determine selected paths, I still don't see this > as a network routing parameter. The node that becomes energy starved > simply needs to stop forwarding routed messages. The transport will > quickly notice that messages are not reaching their destination and > advertise for a new path to which our energy starved device won't > respond. A more graceful approach would be for the energy starved > node to simply tell the source node that it is temporarily out of the > routering business. This functionality needs to be in place anyway > since even in normal operation, an existing path might get blocked. > > By advertising remaining energy throughout the network and making > systemic routing choices based on available energy seems like a nice > thing to do and would tend to balance the total available energy > across the mesh. However, the network also must understand the > application running on the node to make the choice. For example, > let's say I have a battery powered repeater installed in a sparse > portion of the mesh. This device has no other meaning in life but to > route messages. Rerouting around this device saves the energy on a > device that has no reason to save energy. Also, remember this > repeater was strategically placed to 'fill-in' the mesh. By taking it > out of the mesh routes, all the other nodes will need to use up more > of their available energy to make up for this missing node. > > Conversely, (kind of!!!) let's say I have a sensor that needs to > report status temporally. Even if I stop routing, I still need to > awaken to do my own task on a periodic basis. In many cases I can > synchronize my application with the duty cycle of the network. Now I > can continue to perform both jobs without reducing energy any more > than I would performing my one required job. > > My point being that it is important to understand the application > requirements as well as battery status to make judicious routing > decisions. Why not let each device decide no its own if it can save > power by taking itself out of the routing paths. The mesh would then > just re-form as needed around the devices. > > Jerry > > > > > *Kris Pister * > > 11/05/2008 10:08 PM > > > To > Jerald.P.Martocci@jci.com > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > > > > > > > Jerry - I'm not trying to get the IETF decide the threshold for any > flags. My point is that a single bit flag is virtually useless for > making intelligent routing decisions, regardless of what threshold value > you choose for it. > > You say that remaining energy is not a function of time, and yet the > units you use to describe where you set the threshold are "months" :) > Somehow we have to make the same kind of translations between Joules and > months, and for networks where the routers are battery powered, this IS > a routing issue. > > Here's why: ignoring energy in routing decisions, protocol X creates > networks that have a distribution of lifetimes varying, for example, > from three to fifteen years. Protocol Y, using energy in its routing > decisions, builds networks that have the same mean lifetime, but a > distribution that is much tighter - from 9 to 12 years. Which one would > you rather buy? One where you start replacing batteries after 3 years, > or one were you replace them all at 9 years? > > ksjp > > Jerald.P.Martocci@jci.com wrote: > > > > Why is the IETF trying to establish when the energy flag needs to be > > set for low battery? This is an application issue. > > > > Remaining energy is not a function of time, it's a function of > > remaining energy. In our current wireless products, we have a > > comparator that will shut the sensor down at a given voltage level. > > We have actually calculated the number of joules required per > > transaction and have back calculated the voltage level at which point > > we will issue a low-battery alarm. We set the voltage level to alarm > > about 3 months before the device shuts down, giving the customer 3 > > months to change the battery. This is for a device that transmits > > once a minute for about 3 msecs. The battery status is included > > (1-bit). with every transaction. Two alkaline 'c' cells will last > > about 10 years, but due to shelf life, we specify 5 year battery life. > > > > From my viewpoint all battery powered wireless devices need to > > transmit their battery status. For interoperability purposes, this > > should be dictated. However, this is not a protocol issue, much less > > a routing issue. This should be something done by the implementers or > > specified at the alliance level (e.g. IPSO). > > > > Jerry > > > > > > > > > > > > *Kris Pister * > > Sent by: roll-bounces@ietf.org > > > > 11/04/2008 06:06 PM > > > > > > To > > JP Vasseur > > cc > > ROLL WG > > Subject > > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > > > > > > > > > > > > > > > > > Well, we both agree that there will be load imbalance and differential > > rate of energy consumption, > > and we both agree that oscillations will be bad. I think that we may > > have a different picture of the > > frequency of those oscillations, though. I think that most/all of the > > systems described in the > > requirements docs have battery lifetime requirements measured in > > years. This implies a minimum > > update rate of, oh, something like monthly. Sending a few tens of > > bytes of data describing > > energy and power state on a daily basis is both far more frequent than > > we need, and unlikely > > to cause *wasteful* oscillations. If there is some route bouncing > > with a one day or week period, maybe > > that's actually optimal. It's certainly not expensive. > > > > I'm still very curious as to where you think that we should set the > > "low energy" flag level. Based on the two scenarios that I presented, > > I don't see that single-bit flags have much value. As you pointed out > > in your response, the traffic will not be balanced. Either I set the > > flag near midpoint, and it doesn't help much, or I set well below > > midpoint, and it doesn't help very much. > > > > I can imagine scenarios in which it works great. Unfortunately, > > working well 50% of the time doesn't do us much good. We don't have > > to handle every situation, but we have to at least deal with common > > problems that come up in real networks. > > > > ksjp > > > > JP Vasseur wrote: > > Hi Kris, > > > > > > On 11/4/08 6:28 AM, "Kris Pister" __ > > wrote: > > > > > > JP - I'd like to understand more about your flags. > > If I have a network in which I expect that all motes last for 7 years, > > where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 > > years)? At 5% (ideally 3 months)? > > In the first case, for roughly half of my network lifetime, all of my > > network will have set the "I'm low on energy" flag, and I will have no > > useful information with which to make routing decisions. > > In the second case, I have almost no useful information until it's too > > late - one year into operation and several of the busiest motes are > > almost dead, while a mote with a much bigger battery still has almost > > all of it's charge. So in this case the information shows up too late > > to be useful. > > I'm sure that's not the way you see it. What am I missing? > > > > > > > > See it as a trade-off between frequent accurate updates (=> requiring > > energy, risk of routing oscillations, ...) and no information at all. > > If you > > make the assumption of uniform energy consumption, then flags are always > > useless (so does more up to date data). On the other hand if you see > > the use > > of such flags as safeguard mechanisms, this could be useful to start > > rerouting the traffic around nodes running out of battery. Suppose > > that the > > traffic is not equally balanced in the network, you may end up with > nodes > > consuming battery at a much higher rates than others, in which case the > > flags may be useful, with no risk of oscillation. > > > > Thoughts ? > > > > Cheers, > > > > JP. > > > > > > ksjp > > > > JP Vasseur wrote: > > > > Hi Miguel, > > > > > > On 10/31/08 12:24 PM, "Miguel Sanchez" __ > > wrote: > > > > > > > > Hi JP, > > > > > > > > On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur __ > > wrote: > > > > > > Hi Kris, > > > > > > On 10/30/08 5:33 PM, "Kris Pister" __ > > wrote: > > > > I agree with Miguel that we need a standard way of energy reporting, > and I > > agree with JP that it's hard to do. > > Part of the challenge is that energy sources and storage vary so > much. We > > have: > > * line power - great if you can get it! > > * battery storage > > - this is time varying. The available energy in a battery is a > > strong > > function of the temperature and the usage profile. So a battery powered > > mote may correctly calculate five years of lifetime in summer, and then > > that > > winter under the exact same load conditions it may correctly calculate a > > lifetime of ten years. The same mote with the same battery may have > > better > > performance in summer at higher loads. > > > > JP> and usage profile may also change. > > > > * capacitive storage > > * energy scavenging > > - this is time varying, and tough to bound (usefully > > > > JP> this is why I'm questioning the usefulness of knowing the remaining > > energy expressed in Joules or other metrics. Knowing this value will not > > tell you anything as to whether you should or should not use that node > > when > > computing the path. Another metric may be the remaining estimated > lifetime > > > > > > I disagree. > > > > At least if remaining energy is infinitum (mains powered) tells you > > something. > > > > OTOH, if limited, depending on other properties of the nodes (like > > where it gets its energy from) it is also useful for making routing > > decisions too. > > > > > > OK let's try to step back. I'm proposing a flag-based mechanism to > > avoid the > > use of a node should this node run out of energy. The decision to > set the > > flag is made by the node (no specified) according to many parameters > > (estimated like time, ... Etc). Some nodes having more power may make > > use of > > complex models. > > > > If you advertise your remaining power in Joules, how would you > expect the > > nodes to change their routing decisions since they have no idea of > whether > > you are running low in energy (it highly depends on what the node > > does, the > > external conditions, ... Etc) ? > > > > Thanks. > > > > JP. > > > > > > > > but still, is the node capable (without consuming too much energy) of > > gathering historical data etc ... to provide an accurate value > hoping that > > other criterion such as usage profile or temperature as you pointed out > > will > > not change ? > > > > All of this makes energy/power/lifetime reporting painful, yet I can not > > picture a successful routing protocol that doesn't somehow take these > > factors into account. > > > > > > > > Kind regards, > > > > Miguel > > > > > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 15:46:29 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CD63A6A28; Mon, 10 Nov 2008 15:46:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B561E28B797 for ; Mon, 10 Nov 2008 15:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HiBKBtTEjpE for ; Mon, 10 Nov 2008 15:46:27 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 6CF7F3A6A28 for ; Mon, 10 Nov 2008 15:46:27 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAANkL2Q014869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2008 15:46:22 -0800 (PST) Message-ID: <4918C8C4.3020008@eecs.berkeley.edu> Date: Mon, 10 Nov 2008 15:50:28 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: roll@ietf.org Subject: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I agree with Jonathan that aggregation is best left to higher layers. Is there a requirements document that lists aggregation? In my = experience this is one of those clever ideas that never has a real = application. Certainly the concepts of data fusion, distributed signal = processing, and joint source coding have all enjoyed lots of academic = interest, but as far as I know no commercial application. The original vision was that dust would scattered everywhere (jeez, who = came up with *that* crazy idea :) ) and we'd be required to fuse the = data just to make sense of it. For industrial and commercial = applications, the opposite is true - sensors will be placed where they = are needed, typically measuring things that either have no correlation. = More importantly, in most applications listed in the various = requirements documents, all of the data is likely to be encrypted with = end-to-end session keys that do not admit any en route snooping. In the interest of keeping an already large set of attributes smaller, I = recommend that we remove aggregation from the routing layer and let = higher layers deal with it if they want to. ksjp JP Vasseur wrote: > Hi Jonathan, > > > On 11/3/08 7:02 PM, "Jonathan Hui" wrote: > > = >> This draft is an excellent starting point and has already generated a >> lot of good discussion. >> = > > Thanks for the comments, > > Here are some of my own comments: > = >> - Section 4.3 and 4.4: I understand that these are important metrics >> with more traditional (higher power) link technologies, but I think >> the description does not sufficiently characterize the challenges in >> LLNs. = >> = > > JP> Well, except in the case of the "overload" bit used for example for > synchronization purposes between the IGP and BGP (due to slower convergen= ce > of BGP), these metrics are usually not relevant in traditional networks. > > In general, most of the high-order bits in these metrics will be > = >> due to communication delays at the link layer (scheduled communication >> as well as conservative backoffs can cause communication delays on the >> order of seconds and even 10s of seconds). This can easily dwarf all >> other delays caused by processing times. For the networks I'm used to >> dealing with, I'd argue that communication latency is much more >> significant than node workload. >> = > > JP> We are in sync. As pointed out in previous emails, the goal of this > first version was to list *all* metrics and trigger a discussion to make > sure that we only keep the *key* metrics. > > Anyone on this list thinking otherwise with regards to the node workload = and > latency ? > > = >> - Section 4.5: I'm not convinced that the Data Aggregation attribute >> is best to have within the network layer. Data aggregation is >> application specific. The great thing about route-over is that it >> exposes all of the physical connectivity above IP, and doing so >> supports the construction of higher-layer structures (i.e. overlays) >> that can support things like in-network processing. I personally feel >> that data aggregation is best left for higher layers. >> = > > Happy to have that discussion, I do think otherwise ;-) You can always bu= ild > an overlay at the transport or application layer but that requires to car= ry > extra information in the payload, address manipulations, discovery > capabilities (to discover the aggregating nodes), ... Etc. By advertising > data aggregation at the routing layer, this allows routing to compute rou= tes > taking into account the node aggregation capability, thus the destination > remains unchanged and the routing engine potentially elect non shortest > paths (=3D> constrained-based routing) to allow for aggregation. > > = >> - Section 4.6: I share the same concern with Phil. While even DV >> protocols maintain neighbors, the strict resource constraints of LLNs >> often restrict nodes to maintaining state about a *subset* of their >> neighbors. I do believe that maintaining a node's degree in terms of >> bi-directional links will not fit within the resource constraints of >> typical LLNs in the general case. However, degree is a useful metric >> to have, if we can both define and evaluate it properly. >> = > > OK. Furthermore, the node degree is known in link state and requires > significant amount of states in DV, especially when one performs route > aggregation. Finally it only gives an "idea" of the potential backup rout= es. > > = >> - Section 4.7: Agreeing with what was mentioned earlier on the list, >> the distinction between Dynamicity (4.7) and Link Reliability (5.2) >> is not obvious to me. In some sense, we have only marginal control >> over network topology and node behaviors - they are often driven by >> surrounding environmental factors. >> = > > The idea was to have a simple flag used by a node to advertise (when know= n) > if it is a priori a mobile or static node (e.g. Remote control versus > movement detector) whereas the link reliability is not of course related = to > link quality and can significantly vary on nodes with multiple radios or > wired and wireless link. > > Don't you see a use of such a static/mobile node flag ? > > = >> - Section 5.1: I think the metric we really want here is throughput. >> Bandwidth is only one of many factor that affects the link's throughput. >> >> = > > Very good point. Totally agree. > > = >> - Section 5.2: Just a personal opinion here, but I strongly believe >> that bi-directional link success rates (PRR) will be much more useful >> than directional success rates. Due to the lossy nature of LLNs, I >> expect most, if not all, LLNs to utilize link-layer acknowledgments. >> Furthermore, enforcing metrics to be bi-directional have significant >> simplification advantages with respect to routing. >> = > > Mmm ... That does require discussion. Routing is almost always asymmetric= al. > Why would you need symmetrical link metric for routing ? > > = >> - Section 5.3: I suggest renaming this attribute to Path Delay to >> better describe the latency of delivering a message across the entire >> path. = >> = > > JP> This is typo, yes indeed. Furthermore, Path delay is not a routing > metric carried by the protocol. > > Propagation Delay has already caused some confusion on this list > = >> and, as traditionally defined, is fairly insignificant compared to the >> other causes of delivery delays. >> = > > JP> Which leads to the question: "Do we need link propagation delay at all > ?" > > = >> - Section 5.4: As mentioned with 5.2, bi-directional links are not >> just important for routing, but to enable the use of link mechanisms >> such as link-layer acknowledgements. Are there others that feel >> strongly against preferring routes that support relatively good bi- >> directional communication? >> = > > JP> I do see any reason for mandating path to be symmetrical ? > > = >> - Section 6: I think it's best to leave the first paragraph in and >> strike the remaining two. It's useful to give the warning, but we >> don't have to explain how to address it in this draft. >> = > > JP> Well we do need to discuss these issues in the document. We cannot li= st > a set of metrics without specifying how they will be used and their > implication on the routing protocol dynamics. This is one of these exampl= es > where the metrics settings is not an implementation issues. I could menti= on > a number of documents where we had to specify such mechanisms in great > details to pass IESG review (for good reasons !). > > Thanks for the comments. > > Cheers. > > JP. = > > = >> -- >> Jonathan Hui >> >> >> >> On Oct 20, 2008, at 10:14 PM, JP Vasseur wrote: >> >> = >>> Dear WG, >>> >>> As you know, routing metrics for LLN are part of our WG charter. >>> draft-mjkim-roll-routing-metrics-01 is a first draft attempting to >>> list a set of link and node metrics candidates. We intentionally >>> left a wide set of metrics of various nature: link/node, static/ >>> dynamic, ... >>> >>> We of course have to be quite careful here: defining metrics is one >>> thing, determining what to do and how to make a careful use of it is >>> the hard part. There is a number of notorious examples where metrics >>> have been defined but have never been used simply for a number of >>> reasons: >>> =80 Computing an aggregated metric as a polynomial function of a set >>> of metrics is too difficult to operate, >>> =80 Use of a set of attributes as hierarchical constraints implies >>> heavy policy configuration, >>> =80 Use of dynamic metrics was the source of routing oscillations >>> (e.g. ARPANET) >>> =80 .... >>> >>> So we would need your feed-back, bearing in mind that we may want to >>> only keep the metrics that are critical to LLNs. >>> >>> Waiting for your comments ... >>> >>> Thanks. >>> >>> JP and Kim. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> = > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 10 15:53:11 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E1F3A6A7A; Mon, 10 Nov 2008 15:53:11 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F803A69C4 for ; Mon, 10 Nov 2008 15:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3HpRQHWkEua for ; Mon, 10 Nov 2008 15:53:10 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id F30BA3A6AB2 for ; Mon, 10 Nov 2008 15:53:09 -0800 (PST) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAANqcHj014980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Nov 2008 15:52:39 -0800 (PST) Message-ID: <4918CA3D.30903@eecs.berkeley.edu> Date: Mon, 10 Nov 2008 15:56:45 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I'm confident that we can find a relatively short list of metrics that can easily be calculated. The list from HART is actually not all metrics. I was using it to illustrate that the energy problem is complex. On the plus side, we have an existence proof that it's possible to find a stable working solution. I'm happy if we can do as well or better with fewer metrics and slower reporting (15 minutes in hart). Like the Buddha, we look for the middle way, ksjp JP Vasseur wrote: > > JP> I was actually referring to 2 levels of flagging providing > enough flexibility ... But we can think of using a more accurate > model with higher granularity. I personally think that the number > of metrics specified in WHART is too high, may be a 2-flag > mechanism may be too coarse. Then we will have to also specify how > often to set these metrics since this is not in this case an > implementation issue. We will also have to specify how to compute > those metrics. > > Can we try to find a middle ground solution ? > > Cheers. > > JP. > > ksjp > > JP Vasseur wrote: > > > Hi Kris, > > > On 11/4/08 6:28 AM, "Kris Pister" > wrote: > > > > > > JP - I'd like to understand more about your flags. > If I have a network in which I expect that all motes last > for 7 years, > where do I set the "I'm low on energy" flag? At 50% > (ideally 3.5 > years)? At 5% (ideally 3 months)? > In the first case, for roughly half of my network > lifetime, all of my > network will have set the "I'm low on energy" flag, and I > will have no > useful information with which to make routing decisions. > In the second case, I have almost no useful information > until it's too > late - one year into operation and several of the busiest > motes are > almost dead, while a mote with a much bigger battery still > has almost > all of it's charge. So in this case the information shows > up too late > to be useful. > I'm sure that's not the way you see it. What am I missing? > > > > > > > See it as a trade-off between frequent accurate updates (=> > requiring > energy, risk of routing oscillations, ...) and no information > at all. If you > make the assumption of uniform energy consumption, then flags > are always > useless (so does more up to date data). On the other hand if > you see the use > of such flags as safeguard mechanisms, this could be useful to > start > rerouting the traffic around nodes running out of battery. > Suppose that the > traffic is not equally balanced in the network, you may end up > with nodes > consuming battery at a much higher rates than others, in which > case the > flags may be useful, with no risk of oscillation. > > Thoughts ? > > Cheers, > > JP. > > > > > > ksjp > > JP Vasseur wrote: > > > > > Hi Miguel, > > > On 10/31/08 12:24 PM, "Miguel Sanchez" > wrote: > > > > > > > Hi JP, > > > > On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur > > wrote: > > > > > > Hi Kris, > > > On 10/30/08 5:33 PM, "Kris Pister" > > wrote: > > I agree with Miguel that we need a standard > way of energy reporting, and I > agree with JP that it's hard to do. > Part of the challenge is that energy sources > and storage vary so much. We > have: > * line power - great if you can get it! > * battery storage > - this is time varying. The available > energy in a battery is a > strong > function of the temperature and the usage > profile. So a battery powered > mote may correctly calculate five years of > lifetime in summer, and then > that > winter under the exact same load conditions it > may correctly calculate a > lifetime of ten years. The same mote with the > same battery may have better > performance in summer at higher loads. > > JP> and usage profile may also change. > > * capacitive storage > * energy scavenging > - this is time varying, and tough to > bound (usefully > > JP> this is why I'm questioning the usefulness > of knowing the remaining > energy expressed in Joules or other metrics. > Knowing this value will not > tell you anything as to whether you should or > should not use that node when > computing the path. Another metric may be the > remaining estimated lifetime > > > > > > I disagree. > > At least if remaining energy is infinitum (mains > powered) tells you > something. > > OTOH, if limited, depending on other properties of > the nodes (like > where it gets its energy from) it is also useful > for making routing > decisions too. > > > > > > OK let's try to step back. I'm proposing a flag-based > mechanism to avoid the > use of a node should this node run out of energy. The > decision to set the > flag is made by the node (no specified) according to > many parameters > (estimated like time, ... Etc). Some nodes having more > power may make use of > complex models. > > If you advertise your remaining power in Joules, how > would you expect the > nodes to change their routing decisions since they > have no idea of whether > you are running low in energy (it highly depends on > what the node does, the > external conditions, ... Etc) ? > > Thanks. > > JP. > > > > > > > > but still, is the node capable (without > consuming too much energy) of > gathering historical data etc ... to provide > an accurate value hoping that > other criterion such as usage profile or > temperature as you pointed out > will > not change ? > > All of this makes energy/power/lifetime > reporting painful, yet I can not > picture a successful routing protocol that > doesn't somehow take these > factors into account. > > > > > > > Kind regards, > > Miguel > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 11 02:12:54 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C77528C158; Tue, 11 Nov 2008 02:12:54 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D7228C159 for ; Tue, 11 Nov 2008 02:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KukeEkICKEBC for ; Tue, 11 Nov 2008 02:12:50 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 9433028C14E for ; Tue, 11 Nov 2008 02:12:45 -0800 (PST) Received: from leo (postfix@leo.cttc.es [84.88.62.208]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id mABAB4Yq016994; Tue, 11 Nov 2008 11:11:04 +0100 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by leo (Postfix) with ESMTP id 1C4A410C31D; Tue, 11 Nov 2008 11:11:04 +0100 (CET) From: "Mischa Dohler" To: "'Kris Pister'" Date: Tue, 11 Nov 2008 11:07:07 +0100 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4918C2F5.5030809@eecs.berkeley.edu> Thread-Index: AclDi7OhXPQ1x365TBy35fy5sCgZLQAV7U3A Message-Id: <20081111101104.1C4A410C31D@leo> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (leo); Tue, 11 Nov 2008 11:11:04 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: amine@sensysnetworks.com, 'ROLL WG' , 'Tod Dykstra' Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Kris, I actually did not mean to remove latency from the protocol design but rather proposed to omit it from the list of routing metrics since it can more or less be inferred from the number of hops or, more precisely, the number of duty-cycles needed to get the data through - all this, of course, assuming WSN-tailored duty-cycled MACs and not traditional MACs. I have however no strong opinion about this since loads of scenarios immediately pop into my mind where the exact delay matters, such as a combination of what Phil referred to and your TSMP for industrial monitoring. Mischa. PS: Tim (Winter), what do you think about that issue in the context of meter reading? -----Original Message----- From: Kris Pister [mailto:pister@eecs.berkeley.edu] Sent: Tuesday, November 11, 2008 12:26 AM To: mischa.dohler@cttc.es Cc: 'ROLL WG'; Tod Dykstra; amine@sensysnetworks.com Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Mischa - I agree with everything except the second to last sentence. :) I haven't read the urban draft recently, but I tried to convince Thomas to put in the parking monitoring and traffic light applications, since both of those are actually in production already using LLNs (e.g. StreetlineNetworks.com, SensysNetworks.com). In both cases, latency is a real issue. In any case, even meter and meteorological data has latency constraints. There are those who believe that the best way to get below a 0.1% radio duty cycle is to turn all of the radios on for 60 seconds once a day. There was a product on the market for a while that did this with a 15 minute cycle. I disagree with that approach, but it's certainly a LLN MAC that we might see some day, and hopping across networks like that is going to be painful for most applications. ksjp Mischa Dohler wrote: > Hi Mijeom, all, the conclusion on the instability has - if I understood > correctly - always been drawn assuming a fairly heavily loaded network. With > some exceptions, however, our networks will be lightly loaded and > duty-cycled, which means that in most cases the processing + queuing + > transmission delay << L2 delay. Whilst this L2 delay heavily depends on the > MAC, it is not a value which fluctuates strongly (if at all) over time. The > end-to-end delay, will hence more or less be proportional to the number of > hops multiplied by the L2 delay. Therefore, although differently motivated, > I would agree that delay is not really needed. Having said this, in our > urban scenario, delay is not really a design issue - Jerry, Kris and Anders > may have a different opinion here. Regards, Mischa. > > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > MiJeom Kim > Sent: Monday, November 10, 2008 7:07 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Hi, > > We have had quite a few arguments regarding delay related metrics > through this mailing list. In traditional packet switched networks, > there are four kinds of delays, which are processing delay, queuing > delay, transmission delay and propagation delay. There is one more > delay we make an issue here is L2 delay caused by MAC protocols. The > document classifies the first three delays as node latency, one of > node metrics and propagation delay as a link metric. > > Let's take into consideration one by one. > - Processing delay: it's time for a node to process a packet including > header analysis and error check. I personally prefer to exclude > processing delay from metrics since it is kind of negligible and is > depending on node's computing resource which is specified as a node > metric. > - Queuing delay: it is depending on time and current node workload > (the number of packets arrived earlier), thus I prefer to exclude it, > too. > - Transmission delay: it's time to push the packet to the link and > calculated as packet size/bit rate. It's a function of packet size, > which is hard to make it a metric. We can take bit rate as a factor to > affect link throughput, though. > - Propagation delay: as we already agreed, it's close to light speed > in radio systems and negligible. So I don't think we need this as a > metric. > - L2 delay: as I mentioned before, it's very fluctuating by time and > depending on MAC protocols. Due to the all dependency I don't think > it's a good idea to take L2 delay as a metric. > > To summary, delay related attributes are mostly varying as time and > depending on variables such as packet size and workload. Therefore, I > don't think anything above can be a feasible routing metric. > Otherwise, we need really well designed schemes to take care of all > the variables affecting the delays and to avoid instability, which is > pretty skeptical. > > Always welcome other opinions, > > Thanks, > Mijeom. > > On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis wrote: > >> On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: >> >> >>> Hi Mijeom, >>> >>> I suspect that in many radio systems with operations similar to IEEE 802, >>> the propagation delay you are talking about is almost useless taken >>> separately since the transaction is only complete when an ack is received >>> back that enables a wireless router to free the resources allocated to >>> > the > >>> frame and go back to sleep. The time between acking a received frame and >>> receiving the ack for that frame being forwarded is the real latency of a >>> node. If we want to sustain a given rate R with a Latency L, we need R*L >>> > in > >>> buffer space. Considering that memory is often a constrained resource >>> > this > >>> is something that we need to account for. >>> >> Pascal, >> >> I'm not sure this is really an issue. You're talking about layer 2 acks? >> Generally those are always transmitted within a quite deterministic and >> > tiny > >> time interval; furthermore, media access is designed to prevent >> > transmitting > >> on top of them (e.g., through 15.4's double channel sense, or 802.11's >> > NAV). > >> The idea that a node has to hold onto a packet for a long time waiting for >> > a > >> layer 2 ack just isn't a problem, as they are generally synchronous rather >> than asynchronous (do not go through media access). >> >> Phil >> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 11 15:33:30 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892283A6A8C; Tue, 11 Nov 2008 15:33:30 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4653A6A8C for ; Tue, 11 Nov 2008 15:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+7AGpaDn8Z0 for ; Tue, 11 Nov 2008 15:33:28 -0800 (PST) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id 843E53A6A85 for ; Tue, 11 Nov 2008 15:33:28 -0800 (PST) Received: (qmail 65062 invoked from network); 11 Nov 2008 23:33:28 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@209.48.242.70 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 11 Nov 2008 23:33:28 -0000 X-YMail-OSG: KEV7cY8VM1lWwGNE3seky3kcxzcn9dw3d3o5_UYADx2Fp5XXN.BzStJZ3Wza8Fpe5hqrT8WNJYh2LLzWGuP1HtaeoicCum8JoH4fdVuSZ4wYaR0UgqnF9lfFKj6c3vC4z9vM1sgDcIOzwc349ZIkB36k X-Yahoo-Newman-Property: ymail-3 Message-ID: <491A1647.5000502@ekasystems.com> Date: Tue, 11 Nov 2008 18:33:27 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: mischa.dohler@cttc.es References: <20081111101104.1C4A410C31D@leo> In-Reply-To: <20081111101104.1C4A410C31D@leo> Cc: 'ROLL WG' Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In the context of meter reading, periodic reporting of meter data from the meter to the LBR will not generally have tight latency requirements. `Live' meter readings, where, e.g., a specific request is made from a customer support to read a meter while a customer is waiting on the phone will need to be more responsive. In these case the routing protocol should generally support selection of a route based on priority, and it would be useful to be able to make some correlation between priority and latency. But I would agree that this does not necessarily require latency to be a metric on its own- number of hops or some other metric could be used in this application. -Tim Mischa Dohler wrote: > Kris, I actually did not mean to remove latency from the protocol design but > rather proposed to omit it from the list of routing metrics since it can > more or less be inferred from the number of hops or, more precisely, the > number of duty-cycles needed to get the data through - all this, of course, > assuming WSN-tailored duty-cycled MACs and not traditional MACs. I have > however no strong opinion about this since loads of scenarios immediately > pop into my mind where the exact delay matters, such as a combination of > what Phil referred to and your TSMP for industrial monitoring. Mischa. PS: > Tim (Winter), what do you think about that issue in the context of meter > reading? > > > > > -----Original Message----- > From: Kris Pister [mailto:pister@eecs.berkeley.edu] > Sent: Tuesday, November 11, 2008 12:26 AM > To: mischa.dohler@cttc.es > Cc: 'ROLL WG'; Tod Dykstra; amine@sensysnetworks.com > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Mischa - > I agree with everything except the second to last sentence. :) > I haven't read the urban draft recently, but I tried to convince Thomas > to put in the parking monitoring and traffic light applications, since > both of those are actually in production already using LLNs (e.g. > StreetlineNetworks.com, SensysNetworks.com). In both cases, latency is > a real issue. > In any case, even meter and meteorological data has latency > constraints. There are those who believe that the best way to get below > a 0.1% radio duty cycle is to turn all of the radios on for 60 seconds > once a day. There was a product on the market for a while that did this > with a 15 minute cycle. I disagree with that approach, but it's > certainly a LLN MAC that we might see some day, and hopping across > networks like that is going to be painful for most applications. > > ksjp > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 12 03:29:17 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793AD3A67AE; Wed, 12 Nov 2008 03:29:17 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1933A67AE for ; Wed, 12 Nov 2008 03:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1g+AYQStR8Q for ; Wed, 12 Nov 2008 03:29:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B3C333A6784 for ; Wed, 12 Nov 2008 03:29:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,589,1220227200"; d="scan'208,217";a="27554714" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Nov 2008 11:29:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mACBTDKB000675 for ; Wed, 12 Nov 2008 06:29:13 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mACBTC02016481 for ; Wed, 12 Nov 2008 11:29:12 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 06:29:12 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 12 Nov 2008 11:29:04 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 12 Nov 2008 12:28:59 +0100 From: JP Vasseur To: Message-ID: Thread-Topic: New Boiler Template Thread-Index: AclEudr2CrvY0kTBjkiaq/kOOtcJOw== Mime-version: 1.0 X-OriginalArrivalTime: 12 Nov 2008 11:29:12.0954 (UTC) FILETIME=[E347C5A0:01C944B9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6666; t=1226489353; x=1227353353; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20Boiler=20Template |Sender:=20 |To:=20; bh=wc3Cih54EyvAnHBfjPwdJrlcgWU5xvJDNTiGB8fasrg=; b=BNz0j5vhnTEJXvbSRyMUU0r0mv/0ezTwPLR3wpw+q1h2nAcEuPqUTWU2/d bZptLMVZ5XPtF0acN5AH2pRSdgjD560S96yvMa4eCwzBmrW/DghMoWSNUrHQ uQzH5Ay8x+; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] New Boiler Template X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1703417404==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1703417404== Content-type: multipart/alternative; boundary="B_3309337740_30063719" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3309337740_30063719 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ----- Original Message ----- From: "Ed Juskevicius" To: "IETF Discussion" ; ; ; ; ; "RFC Editor" ; Cc: Sent: Tuesday, November 11, 2008 11:03 PM Subject: Announcement: New Boilerplate Text Required for all new Submissionsto IETF > Greetings. This message is to draw your attention to the significance > of the publication of RFC5377 and RFC5378 earlier today. > > * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be > Granted in IETF Documents > * RFC5378 is Rights Contributors Provide to the IETF Trust > > Note that RFC5378 is also BCP0078. RFC5378 is an update to RFC2026, and > RFC5378 obsoletes both RFC3978 and RFC4748. > > Coincident with the above, the IETF Trustees have posted a new policy > document with guidance to the community on: > * Legal Provisions Relating to IETF Documents at > http://trustee.ietf.org/license-info/ > > Taken as a set, the documents listed above specify changes that are now > required in all new submissions into the IETF. > > Henrik Levkowetz has updated the idnit tool and AMS have updated the > Internet-Draft submission tool to reflect the new requirements. An > update to the xml2rfc has been requested. > > Please review the "Legal Provisions Relating to IETF Documents" and > RFC5378 to discover the new boilerplate text that is now required. > Please also take action to update the tools you use for creating your > documents. > > New submissions using either the old or the new boilerplate text will be > accepted starting today, until 01h00 UTC on December 16th, 2008. After > this cutoff date, all new submissions will be required to use ONLY the > new boilerplate text. All submissions using old boilerplate text after > the cutoff date will be rejected. > > Regards and FYI. > > > Ed Juskevicius > IETF Trust Chair > edj@nortel.com > > > p.s. - Don't be surprised if you see periodic reminders about this as we > approach December 16th. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > --B_3309337740_30063719 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable New Boiler Template ----- Original Message -----
From: "Ed Juskevicius" <edj@nortel.com>
To: "IETF Discussion" <ietf@ietf.org>; <ietf-announce@ietf.org>; <ipr-wg@ietf.org<= /U>>; <iesg@ie= tf.org>; <iab@iab.org>; "RFC Editor"
<rfc-editor= @rfc-editor.org>; <wgchairs@ietf.org>
Cc: <trustees@ietf.= org>
Sent: Tuesday, November 11, 2008 11:03 PM
Subject: Announcement: New Boilerplate Text Required for all new
Submissionsto IETF


> Greetings.  This message is to draw your attention to the signifi= cance
> of the publication of RFC5377 and RFC5378 earlier today.
>
> * RFC5377 is Advice to the Trustees of the IETF Trust on Rights to Be<= BR> > Granted in IETF Documents
> * RFC5378 is Rights Contributors Provide to the IETF Trust
>
> Note that RFC5378 is also BCP0078.  RFC5378 is an update to RFC20= 26, and
> RFC5378 obsoletes both RFC3978 and RFC4748.
>
> Coincident with the above, the IETF Trustees have posted a new policy<= BR> > document with guidance to the community on:
> * Legal Provisions Relating to IETF Documents at
> http://trustee.ietf.org/license-info/
>
> Taken as a set, the documents listed above specify changes that are no= w
> required in all new submissions into the IETF.
>
> Henrik Levkowetz has updated the idnit tool and AMS have updated the > Internet-Draft submission tool to reflect the new requirements.  = An
> update to the xml2rfc has been requested.
>
> Please review the "Legal Provisions Relating to IETF Documents&qu= ot; and
> RFC5378 to discover the new boilerplate text that is now required.
> Please also take action to update the tools you use for creating your<= BR> > documents.
>
> New submissions using either the old or the new boilerplate text will = be
> accepted starting today, until 01h00 UTC on December 16th, 2008.  = ;After
> this cutoff date, all new submissions will be required to use ONLY the=
> new boilerplate text.  All submissions using old boilerplate text= after
> the cutoff date will be rejected.
>
> Regards and FYI.
>
>
> Ed Juskevicius
> IETF Trust Chair
> edj@nortel.com >
>
> p.s. - Don't be surprised if you see periodic reminders about this as = we
> approach December 16th.
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
--B_3309337740_30063719-- --===============1703417404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1703417404==-- From roll-bounces@ietf.org Wed Nov 12 09:27:47 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C0A3A6774; Wed, 12 Nov 2008 09:27:47 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EBA3A6774 for ; Wed, 12 Nov 2008 09:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prgukpwA++cl for ; Wed, 12 Nov 2008 09:27:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D61373A6407 for ; Wed, 12 Nov 2008 09:27:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,591,1220227200"; d="scan'208,217";a="27628145" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Nov 2008 17:27:39 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mACHRdVl027988; Wed, 12 Nov 2008 12:27:39 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mACHRdrg006492; Wed, 12 Nov 2008 17:27:39 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 12:27:39 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 12 Nov 2008 17:27:25 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Wed, 12 Nov 2008 18:27:23 +0100 From: JP Vasseur To: JP Vasseur , , Porcu Giorgio , Anders Brandt Message-ID: Thread-Topic: [Roll] WG Last Call: draft-ietf-roll-home-routing-reqs-04 Thread-Index: Ack5u/WqlnqSycdCi0KNbtKx32QT/wLL/atX In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 12 Nov 2008 17:27:39.0280 (UTC) FILETIME=[F60CB100:01C944EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4018; t=1226510859; x=1227374859; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20WG=20Last=20Call=3A=20draft-ie tf-roll-home-routing-reqs-04 |Sender:=20 |To:=20JP=20Vasseur=20,=20,=0A=20=20=20=20=20=20=20=20Porcu=20Giorgio=20,=0A=20=20=20=20=20=20=20=20Anders =20Brandt=20; bh=tR+GV4IB1xc4mRVTIaUz3VF5nHgAbC4Qf5bww2kCnD4=; b=kZEiipDOGMj5p1KWkDI+da3Rme98Qy67eDP8cal/BjOjF1sI5PAz58bGRH 9afGOzPHXldxvT3YQm71DFfFtGLiCT9nyux13mhiq/hyH5v4+gVlyNSfdl4l GHNmeqlrG+; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Roll] WG Last Call: draft-ietf-roll-home-routing-reqs-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0674480599==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0674480599== Content-type: multipart/alternative; boundary="B_3309359244_31334281" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3309359244_31334281 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Since there were no further comments during WG LC, the document is ready fo= r publication. That said, authors, could you please resubmit the document (as early as nex= t Monday if you will) to fix the informative reference section? Currently it looks like this: 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. =20 draft-ietf-roll-indus-routing-reqs-01.txt draft-ietf-roll-urban-routing-reqs-01.txt draft-martocci-roll-commercial-routing-reqs-00.txt draft-ietf-roll-protocols-survey-00.txt draft-vasseur-roll-terminology-02.txt Then I=B9ll send the publication request. Thanks. JP. On 10/29/08 12:46 PM, "JP Vasseur" wrote: > Dear WG, >=20 > This starts a 3-week Working Group Last Call on > draft-ietf-roll-home-routing-reqs-04 ending on Nov 12 at noon ET. Thanks = to > send your comments to the authors and copy the list. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --B_3309359244_31334281 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] WG Last Call: draft-ietf-roll-home-routing-reqs-04</TITLE= > </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:13pt= '>Hi,<BR> <BR> Since there were no further comments during WG LC, the document is ready fo= r publication.<BR> <BR> That said, authors, could you please resubmit the document (as early as nex= t Monday if you will) to fix the informative reference section? Currently it= looks like this:<BR> <BR> </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Courier, Courier New"><SPAN STYLE=3D= 'font-size:10pt'>9.1. Normative References <BR> <BR>    [RFC2119] Bradner, S., "Key words for use in RFCs to= Indicate <BR>             &nb= sp;Requirement Levels", BCP 14, RFC 2119, March 1997. <BR> <BR>     <BR> <BR>    draft-ietf-roll-indus-routing-reqs-01.txt <BR> <BR>    draft-ietf-roll-urban-routing-reqs-01.txt <BR> <BR>    draft-martocci-roll-commercial-routing-reqs-00.txt <BR> <BR>    draft-ietf-roll-protocols-survey-00.txt <BR> <BR>    draft-vasseur-roll-terminology-02.txt<BR> </SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:13pt'><BR> Then I’ll send the publication request.<BR> <BR> Thanks.<BR> <BR> JP.<BR> <BR> On 10/29/08 12:46 PM, "JP Vasseur" <<a href=3D"jvasseur@cisco.co= m">jvasseur@cisco.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= SPAN STYLE=3D'font-size:14pt'>Dear WG,<BR> <BR> This starts a 3-week Working Group Last Call on draft-ietf-roll-home-routin= g-reqs-04 ending on Nov 12 at noon ET. Thanks to send your comments to the a= uthors and copy the list.<BR> <BR> Thanks.<BR> <BR> JP.<BR> </SPAN><SPAN STYLE=3D'font-size:13pt'><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><= /SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Consolas, Courier New, Courier"><SPA= N STYLE=3D'font-size:10pt'>_______________________________________________<BR> Roll mailing list<BR> <a href=3D"Roll@ietf.org">Roll@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/roll">https://www.ietf.org/m= ailman/listinfo/roll</a><BR> </SPAN></FONT></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3309359244_31334281-- --===============0674480599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0674480599==-- From roll-bounces@ietf.org Wed Nov 12 11:42:20 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823ED3A69C7; Wed, 12 Nov 2008 11:42:20 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B22E28C14D for <roll@core3.amsl.com>; Wed, 12 Nov 2008 11:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X3C8-cFArzl for <roll@core3.amsl.com>; Wed, 12 Nov 2008 11:42:19 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 2B7E93A6883 for <roll@ietf.org>; Wed, 12 Nov 2008 11:42:19 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so418753ywj.49 for <roll@ietf.org>; Wed, 12 Nov 2008 11:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=FyCsvriUcMk7QZAam0DKLL/7dilelPQc4yTKMubXzn4=; b=HHXPjAUQdYrv5fsUyEO7NAhkCBowFLHsDUK+Us83N9afTsLfbAjj1P70Hzn9Bw5Og9 FcN/ke9UC0vLUSwJ17po+0oRDlKT7KXnKu2VmIJUV54yEiwAx3hV1TtQfvsDnN6i5xRf U6iuQKFUkCiDXncexOT4UE09BL1U5Zgw93bd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=k/xfJeYT9KGVia1pZtpslOkt3DjfuYhAsbTVr4KD5P3JxCeC0wCFQFqoKHbuvukS6R EGq76LW5f4gF5nrj+SoLAgKemGfd23VIN6N98p0IChPMJT0UvAKS/VREE5ZsjWDbzLDd YSCvnyF2/U1K2djbLmpxubWAnIncTROT7ir88= Received: by 10.90.67.10 with SMTP id p10mr2500209aga.71.1226518939330; Wed, 12 Nov 2008 11:42:19 -0800 (PST) Received: by 10.90.102.19 with HTTP; Wed, 12 Nov 2008 11:42:19 -0800 (PST) Message-ID: <d4dcddd20811121142g3ff29383q7a3a9d53348042ab@mail.gmail.com> Date: Wed, 12 Nov 2008 11:42:19 -0800 From: "Omprakash Gnawali" <gnawali@usc.edu> To: "Jonathan Hui" <jhui@archrock.com> In-Reply-To: <2853C451-5AD6-4650-B5E2-AB3DFB1D0494@archrock.com> MIME-Version: 1.0 Content-Disposition: inline References: <C52331CB.57D41%jvasseur@cisco.com> <628C538F-D023-482F-8C94-047D87A49DDC@archrock.com> <fa3e97a60811032346g3b44dadbhf251e4d262648ddf@mail.gmail.com> <2853C451-5AD6-4650-B5E2-AB3DFB1D0494@archrock.com> X-Google-Sender-Auth: 4160726bf28528a1 Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Mon, Nov 10, 2008 at 8:21 AM, Jonathan Hui <jhui@archrock.com> wrote: ... > On Nov 3, 2008, at 11:46 PM, MiJeom Kim wrote: ... >>> - Section 4.5: I'm not convinced that the Data Aggregation attribute is >>> best to have within the network layer. Data aggregation is application >>> specific. The great thing about route-over is that it exposes all of the >>> physical connectivity above IP, and doing so supports the construction of >>> higher-layer structures (i.e. overlays) that can support things like >>> in-network processing. I personally feel that data aggregation is best left >>> for higher layers. >>> >>> ==> I agree that data aggregation is application or traffic dependent. >>> Let's hear other's opinion. > > [jhui] In some cases, unicast routing is not always the best way to > aggregate information between nodes that are within physical proximity. Unless we are talking about self identifying data (and we are not talking about that), how will aggregation work without application specific data processing code in the forwarding plane? Even concatenation will require major assumptions about data layout. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 12 15:38:25 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D283A6B56; Wed, 12 Nov 2008 15:38:25 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D725C3A6B56 for <roll@core3.amsl.com>; Wed, 12 Nov 2008 15:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfi5RN6TPnJ4 for <roll@core3.amsl.com>; Wed, 12 Nov 2008 15:38:23 -0800 (PST) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id 4EEFB3A63D2 for <roll@ietf.org>; Wed, 12 Nov 2008 15:38:22 -0800 (PST) Received: (qmail 79652 invoked from network); 12 Nov 2008 23:38:22 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@209.48.242.70 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 12 Nov 2008 23:38:21 -0000 X-YMail-OSG: zl1jhuQVM1kNy_qBVdAaD9Z2Pr6EtSurpal91PwOvmoQYJxCHr3THKoa8uu_vMCebK698hoAFFn39fatRjdQS7Hbk9hf5bA5GS8Ng.6xazji9uq..Ixg60Z.MLaiiElFKVamB6OnbOC4tuf9YwbUHzSAYvSo7fJ.DLxBuVr7vpEe0TOWDArmceiS77VH X-Yahoo-Newman-Property: ymail-3 Message-ID: <491B68EC.2030209@ekasystems.com> Date: Wed, 12 Nov 2008 18:38:20 -0500 From: Tim Winter <tim.winter@ekasystems.com> User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Kris Pister <pister@eecs.berkeley.edu> References: <C535F5AD.5BEF5%jvasseur@cisco.com> <4918C8C4.3020008@eecs.berkeley.edu> In-Reply-To: <4918C8C4.3020008@eecs.berkeley.edu> Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org One useful application of aggregation would be in an electricity metering scenario when a power outage occurs. In this application many (previously powered) nodes may find themselves running on a `last gasp' power source such as a capacitor. The goal would be allow as many sensors as possible to relay their outage status before the last gasp source is exhausted, so that a utility can better pinpoint the region affected by the outage. In this scenario, being able to apply a routing strategy to forward data toward nodes capable of aggregation may allow the network to relay much more outage information before backup power is exhausted. -Tim Kris Pister wrote: > I agree with Jonathan that aggregation is best left to higher layers. > Is there a requirements document that lists aggregation? In my > experience this is one of those clever ideas that never has a real > application. Certainly the concepts of data fusion, distributed signal > processing, and joint source coding have all enjoyed lots of academic > interest, but as far as I know no commercial application. > The original vision was that dust would scattered everywhere (jeez, > who came up with *that* crazy idea :) ) and we'd be required to fuse > the data just to make sense of it. For industrial and commercial > applications, the opposite is true - sensors will be placed where they > are needed, typically measuring things that either have no > correlation. More importantly, in most applications listed in the > various requirements documents, all of the data is likely to be > encrypted with end-to-end session keys that do not admit any en route > snooping. > In the interest of keeping an already large set of attributes smaller, > I recommend that we remove aggregation from the routing layer and let > higher layers deal with it if they want to. > > ksjp > > JP Vasseur wrote: >> Hi Jonathan, >> >> >> On 11/3/08 7:02 PM, "Jonathan Hui" <jhui@archrock.com> wrote: >> >> = >>> This draft is an excellent starting point and has already generated a >>> lot of good discussion. >>> = >> >> Thanks for the comments, >> >> Here are some of my own comments: >> = >>> - Section 4.3 and 4.4: I understand that these are important metrics >>> with more traditional (higher power) link technologies, but I think >>> the description does not sufficiently characterize the challenges in >>> LLNs. = >> >> JP> Well, except in the case of the "overload" bit used for example for >> synchronization purposes between the IGP and BGP (due to slower >> convergence >> of BGP), these metrics are usually not relevant in traditional networks. >> >> In general, most of the high-order bits in these metrics will be >> = >>> due to communication delays at the link layer (scheduled communication >>> as well as conservative backoffs can cause communication delays on the >>> order of seconds and even 10s of seconds). This can easily dwarf all >>> other delays caused by processing times. For the networks I'm used to >>> dealing with, I'd argue that communication latency is much more >>> significant than node workload. >>> = >> >> JP> We are in sync. As pointed out in previous emails, the goal of this >> first version was to list *all* metrics and trigger a discussion to make >> sure that we only keep the *key* metrics. >> >> Anyone on this list thinking otherwise with regards to the node >> workload and >> latency ? >> >> = >>> - Section 4.5: I'm not convinced that the Data Aggregation attribute >>> is best to have within the network layer. Data aggregation is >>> application specific. The great thing about route-over is that it >>> exposes all of the physical connectivity above IP, and doing so >>> supports the construction of higher-layer structures (i.e. overlays) >>> that can support things like in-network processing. I personally feel >>> that data aggregation is best left for higher layers. >>> = >> >> Happy to have that discussion, I do think otherwise ;-) You can >> always build >> an overlay at the transport or application layer but that requires to >> carry >> extra information in the payload, address manipulations, discovery >> capabilities (to discover the aggregating nodes), ... Etc. By >> advertising >> data aggregation at the routing layer, this allows routing to compute >> routes >> taking into account the node aggregation capability, thus the >> destination >> remains unchanged and the routing engine potentially elect non shortest >> paths (=3D> constrained-based routing) to allow for aggregation. >> >> = >>> - Section 4.6: I share the same concern with Phil. While even DV >>> protocols maintain neighbors, the strict resource constraints of LLNs >>> often restrict nodes to maintaining state about a *subset* of their >>> neighbors. I do believe that maintaining a node's degree in terms of >>> bi-directional links will not fit within the resource constraints of >>> typical LLNs in the general case. However, degree is a useful metric >>> to have, if we can both define and evaluate it properly. >>> = >> >> OK. Furthermore, the node degree is known in link state and requires >> significant amount of states in DV, especially when one performs route >> aggregation. Finally it only gives an "idea" of the potential backup >> routes. >> >> = >>> - Section 4.7: Agreeing with what was mentioned earlier on the list, >>> the distinction between Dynamicity (4.7) and Link Reliability (5.2) >>> is not obvious to me. In some sense, we have only marginal control >>> over network topology and node behaviors - they are often driven by >>> surrounding environmental factors. >>> = >> >> The idea was to have a simple flag used by a node to advertise (when >> known) >> if it is a priori a mobile or static node (e.g. Remote control versus >> movement detector) whereas the link reliability is not of course >> related to >> link quality and can significantly vary on nodes with multiple radios or >> wired and wireless link. >> >> Don't you see a use of such a static/mobile node flag ? >> >> = >>> - Section 5.1: I think the metric we really want here is throughput. >>> Bandwidth is only one of many factor that affects the link's >>> throughput. >>> >>> = >> >> Very good point. Totally agree. >> >> = >>> - Section 5.2: Just a personal opinion here, but I strongly believe >>> that bi-directional link success rates (PRR) will be much more useful >>> than directional success rates. Due to the lossy nature of LLNs, I >>> expect most, if not all, LLNs to utilize link-layer acknowledgments. >>> Furthermore, enforcing metrics to be bi-directional have significant >>> simplification advantages with respect to routing. >>> = >> >> Mmm ... That does require discussion. Routing is almost always >> asymmetrical. >> Why would you need symmetrical link metric for routing ? >> >> = >>> - Section 5.3: I suggest renaming this attribute to Path Delay to >>> better describe the latency of delivering a message across the entire >>> path. = >> >> JP> This is typo, yes indeed. Furthermore, Path delay is not a routing >> metric carried by the protocol. >> >> Propagation Delay has already caused some confusion on this list >> = >>> and, as traditionally defined, is fairly insignificant compared to the >>> other causes of delivery delays. >>> = >> >> JP> Which leads to the question: "Do we need link propagation delay >> at all >> ?" >> >> = >>> - Section 5.4: As mentioned with 5.2, bi-directional links are not >>> just important for routing, but to enable the use of link mechanisms >>> such as link-layer acknowledgements. Are there others that feel >>> strongly against preferring routes that support relatively good bi- >>> directional communication? >>> = >> >> JP> I do see any reason for mandating path to be symmetrical ? >> >> = >>> - Section 6: I think it's best to leave the first paragraph in and >>> strike the remaining two. It's useful to give the warning, but we >>> don't have to explain how to address it in this draft. >>> = >> >> JP> Well we do need to discuss these issues in the document. We >> cannot list >> a set of metrics without specifying how they will be used and their >> implication on the routing protocol dynamics. This is one of these >> examples >> where the metrics settings is not an implementation issues. I could >> mention >> a number of documents where we had to specify such mechanisms in great >> details to pass IESG review (for good reasons !). >> >> Thanks for the comments. >> >> Cheers. >> >> JP. >> = >>> -- = >>> Jonathan Hui >>> >>> >>> >>> On Oct 20, 2008, at 10:14 PM, JP Vasseur wrote: >>> >>> = >>>> Dear WG, >>>> >>>> As you know, routing metrics for LLN are part of our WG charter. >>>> draft-mjkim-roll-routing-metrics-01 is a first draft attempting to >>>> list a set of link and node metrics candidates. We intentionally >>>> left a wide set of metrics of various nature: link/node, static/ >>>> dynamic, ... >>>> >>>> We of course have to be quite careful here: defining metrics is one >>>> thing, determining what to do and how to make a careful use of it is >>>> the hard part. There is a number of notorious examples where metrics >>>> have been defined but have never been used simply for a number of >>>> reasons: >>>> =80 Computing an aggregated metric as a polynomial function of a set >>>> of metrics is too difficult to operate, >>>> =80 Use of a set of attributes as hierarchical constraints implies >>>> heavy policy configuration, >>>> =80 Use of dynamic metrics was the source of routing oscillations >>>> (e.g. ARPANET) >>>> =80 .... >>>> >>>> So we would need your feed-back, bearing in mind that we may want to >>>> only keep the metrics that are critical to LLNs. >>>> >>>> Waiting for your comments ... >>>> >>>> Thanks. >>>> >>>> JP and Kim. >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> = >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 12 18:47:23 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27213A68F0; Wed, 12 Nov 2008 18:47:23 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670663A68F0 for <roll@core3.amsl.com>; Wed, 12 Nov 2008 18:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70tQUcX6B-zd for <roll@core3.amsl.com>; Wed, 12 Nov 2008 18:47:21 -0800 (PST) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.245]) by core3.amsl.com (Postfix) with ESMTP id A48F33A68E4 for <roll@ietf.org>; Wed, 12 Nov 2008 18:47:21 -0800 (PST) Received: by hs-out-0708.google.com with SMTP id 4so339710hsl.5 for <roll@ietf.org>; Wed, 12 Nov 2008 18:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=AXoEJXLWwituYU8CCx/G1fQmaYZymC3zKFV68IxRqaE=; b=hSV6A+v6NrYSXu1MsQc9NlQpAraOiQrkSIDgEGJbv4LZ0krQ77nEW6zakaTma6Bgm4 HbcZIS7QeI4bj+MZ1Bo9Cg9QgV0C6WokhW8e5b3wGxdGwITDLqCdV+SE4GHc80vPxkbS NzQt8USziLbAmc8xXIf1hzhgej2vTUGZHTv/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=VwEWYq7pQq28YKZNGIfjXH7YkrIHSkUspGMiexXXHDSuu3d9RiTgMfrWko7SeyLgCd /Y6fj8MAzLJC/O8VTKZKG8Rung1r3W1cdAvRTO05MSNjsJBrhDucKtsjLzFNA7h6WJC4 aq0KI0ODodWb1gIWLWa95wqWIVHj2MR5ct9Bc= Received: by 10.90.93.8 with SMTP id q8mr8816381agb.38.1226544439068; Wed, 12 Nov 2008 18:47:19 -0800 (PST) Received: by 10.90.102.19 with HTTP; Wed, 12 Nov 2008 18:47:19 -0800 (PST) Message-ID: <d4dcddd20811121847y38cbfc63l9b46d59e9594b3b0@mail.gmail.com> Date: Wed, 12 Nov 2008 18:47:19 -0800 From: "Omprakash Gnawali" <gnawali@usc.edu> To: "Tim Winter" <tim.winter@ekasystems.com> In-Reply-To: <491B68EC.2030209@ekasystems.com> MIME-Version: 1.0 Content-Disposition: inline References: <C535F5AD.5BEF5%jvasseur@cisco.com> <4918C8C4.3020008@eecs.berkeley.edu> <491B68EC.2030209@ekasystems.com> X-Google-Sender-Auth: 23cd2216f6beb840 Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Wed, Nov 12, 2008 at 3:38 PM, Tim Winter <tim.winter@ekasystems.com> wrote: > One useful application of aggregation would be in an electricity > metering scenario when a power outage occurs. In this application many > (previously powered) nodes may find themselves running on a `last gasp' > power source such as a capacitor. The goal would be allow as many > sensors as possible to relay their outage status before the last gasp > source is exhausted, so that a utility can better pinpoint the region > affected by the outage. > In this scenario, being able to apply a routing strategy to forward data > toward nodes capable of aggregation may allow the network to relay much > more outage information before backup power is exhausted. > > -Tim > What does the proposed aggregation metric look like? Is it a bit? Is this metric different from some combination of "resource" metric such as CPU, RAM, storage, energy? Yes, in theory but in practice there is probably no difference. If a packet arrives at a node with gigabytes of storage or uses wall power, it probably does not matter if the data is aggregated. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 12 19:32:53 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422413A68DF; Wed, 12 Nov 2008 19:32:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF48B3A68DF for <roll@core3.amsl.com>; Wed, 12 Nov 2008 19:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 247Mmu+Xff85 for <roll@core3.amsl.com>; Wed, 12 Nov 2008 19:32:52 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id B590E3A6817 for <roll@ietf.org>; Wed, 12 Nov 2008 19:32:51 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so385731nfh.39 for <roll@ietf.org>; Wed, 12 Nov 2008 19:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=3rNlZ8woNEiOihCykfvn1/gQAmValZvEU4SjEGw82wE=; b=GPEYkpc1cczHN8kH+XXVvSDP9lRPus5FB0ItuU8v1KfmDF7rYl/gFmDtYhkTwlT1rM d7/V1BRP8Tu+OOOzF+gc5pjt7nNURlUn2OCPneGSD7SLdDBcdpi6KE9nW5XVBKfywcgI bREgZ4xppxBGmckYkBb3ALOZExZamtuxpS6hE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=o7E4M5SyzBi2lSuxDYMpLkHlxqBwcfUTAZqp4hEE/jj0IMZ4Uc39FwY9OtjXwQz38o zXllWlQgXActkc3m5BgTG0f+1vZRV61Zzr6G+h4gZ3ZuTyH9XIGut3/EYfNi6biHsXYy fT7Zo87NWoUr7VBcOdj/EdrBwoM/u2DDA6C3A= Received: by 10.210.28.6 with SMTP id b6mr1196115ebb.68.1226547170045; Wed, 12 Nov 2008 19:32:50 -0800 (PST) Received: by 10.210.37.8 with HTTP; Wed, 12 Nov 2008 19:32:50 -0800 (PST) Message-ID: <69306dde0811121932o7cf8ffdladf54b81b021369d@mail.gmail.com> Date: Wed, 12 Nov 2008 19:32:50 -0800 From: "Arsalan Tavakoli" <arsalan@cs.berkeley.edu> To: roll@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 2829e2aa68333c10 Subject: [Roll] draft-ietf-roll-protocols-survey-02 updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org At the interim meeting, Phil presented draft-ietf-roll-protocols-survey-01, and we interactively worked through a set of changes, namely to the five main criteria. The main change was to the control cost criteria, which was changed as follows: a protocol now failed if the control cost was unbounded by the data rate plus a small constant. The small constant allows a protocol to have rare periodic maintenance beacons in the absence of data-traffic, for example, in an event-driven workload. The only protocol evaluation affected was RIP, which now received a pass for control cost, but a fail for node cost, leaving it with the same number of passing grades. These changes were embodied in the latest revision of the draft, draft-ietf-roll-protocols-survey-02. One additional change in the document is that the control cost fail criteria has been slightly modified to: Fail if the control cost is not bounded by O (R log( L) + e), where R is the data rate, L is the neighborhood density, and e is a small constant. The reasoning for the shift to a log-based bound is that packet losses lead to multiple transmissions (and subsequent receptions). More detailed analysis is provided in the draft. As I will only touch on this draft briefly at the IETF meeting next week, I wanted to put it out on the list so any feedback could be addressed, so comments are welcome. Thanks, Arsalan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 12 20:29:32 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5313B3A687B; Wed, 12 Nov 2008 20:29:32 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C533A687B for <roll@core3.amsl.com>; Wed, 12 Nov 2008 20:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu-AkAmHGX3s for <roll@core3.amsl.com>; Wed, 12 Nov 2008 20:29:30 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id DF4DB3A6803 for <roll@ietf.org>; Wed, 12 Nov 2008 20:29:30 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.104]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1L0Tpj-0000b3-Em; Wed, 12 Nov 2008 20:29:31 -0800 Message-Id: <4290E5A1-D056-4F31-A915-1CF0971DEB57@cs.stanford.edu> From: Philip Levis <pal@cs.stanford.edu> To: Arsalan Tavakoli <arsalan@cs.berkeley.edu> In-Reply-To: <69306dde0811121932o7cf8ffdladf54b81b021369d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 20:29:30 -0800 References: <69306dde0811121932o7cf8ffdladf54b81b021369d@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-protocols-survey-02 updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 12, 2008, at 7:32 PM, Arsalan Tavakoli wrote: > At the interim meeting, Phil presented > draft-ietf-roll-protocols-survey-01, and we interactively worked > through a set of changes, namely to the five main criteria. The main > change was to the control cost criteria, which was changed as follows: > a protocol now failed if the control cost was unbounded by the data > rate > plus a small constant. The small constant allows a protocol to have > rare periodic maintenance beacons in the absence of data-traffic, for > example, in an event-driven workload. The only protocol evaluation > affected was RIP, which now received a pass for control cost, but a > fail for node cost, leaving it with the same number of passing grades. > These changes were embodied in the latest revision of the draft, > draft-ietf-roll-protocols-survey-02. One additional change in the > document is that the control > cost fail criteria has been slightly modified to: Fail if the control > cost is not bounded by O (R log( L) + e), NB: I think Arsalan meant to say "is now bounded by" > where R is the data rate, L > is the neighborhood density, and e is a small constant. The reasoning > for the shift to a log-based bound is that packet losses lead to > multiple transmissions (and subsequent receptions). More detailed > analysis is provided in the draft. > > As I will only touch on this draft briefly at the IETF meeting next > week, I wanted to put it out on the list so any feedback could be > addressed, so comments are welcome. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 13 01:48:18 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F6C3A6807; Thu, 13 Nov 2008 01:48:18 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7203A6807 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 01:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7pOukQphtx9 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 01:48:16 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BFB203A67AC for <roll@ietf.org>; Thu, 13 Nov 2008 01:48:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,596,1220227200"; d="scan'208";a="27713385" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Nov 2008 09:48:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAD9mDJq010341; Thu, 13 Nov 2008 04:48:13 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAD9mDIh002766; Thu, 13 Nov 2008 09:48:13 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 04:48:13 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Nov 2008 09:43:38 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Thu, 13 Nov 2008 10:43:36 +0100 From: JP Vasseur <jvasseur@cisco.com> To: Jonathan Hui <jhui@archrock.com>, "Schoofs, Anthony" <anthony.schoofs@philips.com> Message-ID: <C541B558.5DCBA%jvasseur@cisco.com> Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclFdEyTcevZPwfwG0iM3fHlZLAsRw== In-Reply-To: <DC4F597C-47D7-43AB-83B7-A27FEEB4FC98@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 13 Nov 2008 09:48:13.0595 (UTC) FILETIME=[F208B6B0:01C94574] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7310; t=1226569693; x=1227433693; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Jonathan=20Hui=20<jhui@archrock.com>,=0A=20=20=20=20 =20=20=20=20=22Schoofs,=20Anthony=22=20<anthony.schoofs@phil ips.com>; bh=yVF7WU2tYyjhUKI4hdWznM/bzbZjdAuEXZQwFWWc3Zw=; b=Im3woC7wBKptSZKqEERZMXrj7JkvpmeQxSBx48glE6njgDX370M9pUDIWv WtHbjHGx+Ur3rSjdg0RBlnZLb43XvTYDwJv1H/6hqIZmSKI9G8KdK/8wsobf 87HOrD0diF; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG <roll@ietf.org> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org And still, it is far from being obvious that such metric is useful at all. One can of course specify heuristic to make "some" use of it ... But I'm personally not convince at all, as many of you of the list. Cheers, JP. On 11/10/08 7:33 PM, "Jonathan Hui" <jhui@archrock.com> wrote: > = > Hi Anthony, > = > On Nov 10, 2008, at 10:16 AM, Schoofs, Anthony wrote: >> If this implies that you need to maintain a list for an arbitrary >> number of neighbors , then it is indeed not favorable. >> If you are only interested in the number of neighbours, there may be >> some ways to deliver that number without having to maintain a list >> of neighbors. For example (just a try), adding +1 to a Node degree >> variable for each new ICMP message (RS or RR) received by a LowPAN >> router and have the variable reseted periodically (depending on the >> RS and RR refresh periods of the LowPAN hosts) could give a node >> degree to LowPAN routers. > = > This requires nodes to broadcast beacons with a fixed period and > implies that beacon periods are not adaptive to local conditions - not > good characteristics if we're trying to develop an energy efficient > protocol. > = > -- > Jonathan Hui > = >> Besides, I also agree that we shoud consider first whether we need >> the Node degree metric. >> = >> Best regards, >> Anthony >> = >> ________________________________________ >> From: Jonathan Hui [jhui@archrock.com] >> Sent: Monday, November 10, 2008 5:24 PM >> To: Schoofs, Anthony >> Cc: JP Vasseur; MiJeom Kim; Philip Levis; ROLL WG >> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> = >> Hi Anthony, >> = >> This implies that nodes will have sufficient capabilities to maintain >> a list for an arbitrary number of neighbors. In some cases, a node may >> have hundreds of neighbors and the routing protocol should not fail >> simply because it cannot maintain state for a significant portion of >> them. >> = >> -- >> Jonathan Hui >> = >> = >> = >> On Nov 5, 2008, at 1:12 AM, Schoofs, Anthony wrote: >> = >>> In 6lowPAN networks, a node may be able to calculate its degree >>> thanks to 6lowpan Neighbor Discovery mechanisms. >>> LowPAN routers could know how many nodes are surrounding them via >>> Router Solicitations and Router Registration messages they receive >>> from neighboring nodes. >>> Because these mechanisms are repeated periodically, LowPAN Routers >>> may be able to maintain a =B3fresh=B2 node degree without having to >>> generate extra packets. >>> = >>> Best regards, >>> Anthony >>> = >>> = >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of JP Vasseur >>> Sent: Tuesday 4 November 2008 9:31 >>> To: MiJeom Kim; Philip Levis >>> Cc: ROLL WG >>> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >>> = >>> Hi, >>> = >>> = >>> On 11/3/08 10:19 AM, "MiJeom Kim" <mijeom@gmail.com> wrote: >>> Hi, Phil, >>> = >>> You are absolutely right. I missed link asymmetry. >>> However, in link state protocols, nodes keep the list of neighbors. >>> = >>> JP> In link state each node knows the entire topology, thus the set >>> of neighbors. >>> = >>> Even in distance vector protocols, I think there is a high chance >>> for nodes to be aware of their neighbors as time goes. As you >>> mentioned, for constrained nodes, it might be overhead to keep the >>> neighbor list. But, I don't think it is very resource consuming to >>> find out the neighbors unless considering very dynamic networks. >>> = >>> JP> This is clearly a tradeoff between protocol overhead to keep >>> track of a list of neighbors (potentially not a negligible amount of >>> data) compared to what it brings to routing. If the motivation is to >>> compute alternate routes, there are other technique and the node >>> degree is not sufficient to compute diverse path anyway so this >>> would at best be used as a heuristic. >>> = >>> My main concern is whether we need the node degree as a LLN routing >>> metric and if we do, how we manipulate it. As the document says, it >>> is questionable whether high node degrees are preferable or not. The >>> decision requires too many factors need to be considered. >>> Consequently, it's challenging to make use of node degree as a >>> metric. >>> = >>> JP> Right. >>> = >>> So .. I guess that we have a WG consensus not to use it. >>> = >>> Anybody with a different opinion ? >>> = >>> Thanks. >>> = >>> JP. >>> = >>> Thanks. >>> Mijeom. >>> = >>> On Sat, Nov 1, 2008 at 1:13 AM, Philip Levis <pal@cs.stanford.edu> >>> wrote: >>> = >>> On Oct 31, 2008, at 1:20 AM, MiJeom Kim wrote: >>> = >>> 4.6: Is the intention that a node calculates its degree? This is >>> very difficult (some might say impossible under any realistic >>> network scenario). First, it requires O(n^2) communication. The >>> observation that routing protocols might want to change decisions >>> based on density makes sense, but by stating it is a metric that >>> implies nodes calculate it. >>> =3D=3D=3D> >>> I think a node can figure out its degree by overhearing. So as time >>> goes, it can get the number of neighbors more precisely. >>> = >>> That would be true if degree were defined as the number of neighbors >>> a node can hear. However, it's defined as >>> = >>> Node degree is the number of neighbors that can receive a message >>> from the node directly. >>> = >>> Unless you assume asymmetric links do not exist, this requires each >>> node to report the set of nodes from which it hears messages, so >>> those nodes can calculate their degree. It also requires a node to >>> maintain state linear in the number of its neighbors, which is >>> problematic. >>> = >>> Phil >>> = >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> = >>> The information contained in this message may be confidential and >>> legally protected under applicable law. The message is intended >>> solely for the addressee(s). If you are not the intended recipient, >>> you are hereby notified that any use, forwarding, dissemination, or >>> reproduction of this message is strictly prohibited and may be >>> unlawful. If you are not the intended recipient, please contact the >>> sender by return e-mail and destroy all copies of the original >>> message. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> = >> = >> The information contained in this message may be confidential and >> legally protected under applicable law. The message is intended >> solely for the addressee(s). If you are not the intended recipient, >> you are hereby notified that any use, forwarding, dissemination, or >> reproduction of this message is strictly prohibited and may be >> unlawful. If you are not the intended recipient, please contact the >> sender by return e-mail and destroy all copies of the original >> message. > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 13 02:42:32 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2353A6868; Thu, 13 Nov 2008 02:42:32 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F5A3A6868 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 02:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exBU03AxqHbF for <roll@core3.amsl.com>; Thu, 13 Nov 2008 02:42:29 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 716623A6856 for <roll@ietf.org>; Thu, 13 Nov 2008 02:42:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,596,1220227200"; d="scan'208";a="27716385" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Nov 2008 10:42:29 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mADAgTUN026400; Thu, 13 Nov 2008 05:42:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mADAgT2p013888; Thu, 13 Nov 2008 10:42:29 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 05:42:29 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Nov 2008 10:38:26 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Thu, 13 Nov 2008 11:38:24 +0100 From: JP Vasseur <jvasseur@cisco.com> To: Kris Pister <pister@eecs.berkeley.edu>, Philip Levis <pal@cs.stanford.edu> Message-ID: <C541C230.5DCE5%jvasseur@cisco.com> Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclFe/RgnK8PMC6du0OlH3oUdAJRPQ== In-Reply-To: <4918BB25.7030405@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 13 Nov 2008 10:42:29.0386 (UTC) FILETIME=[86A2FEA0:01C9457C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3763; t=1226572949; x=1227436949; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Kris=20Pister=20<pister@eecs.berkeley.edu>,=20Philip =20Levis=20<pal@cs.stanford.edu>; bh=mGmaxzd0TL8Ih1KPIjCH/F9i3Run7dVMSZecm4PBWa4=; b=E68UIXLB2SX6vn1QqDVXnizCxfTcmDRqylrJSMQXM6yg0MiVmV4ddfPHOu FvyPij1OLvYmEpbBrZ7tlzGg+hkICqRST4JnwbV+xU5fe8aX0fWoKxTOam0b sYcsGUV/zT; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG <roll@ietf.org> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 11/10/08 11:52 PM, "Kris Pister" <pister@eecs.berkeley.edu> wrote: > Phil - I agree that the optimal routes are going to be a function of the > state of all of the nodes along each route, not just one node > advertising that it's fat and happy. Right. Bear in mind that we are discussing node metric. Path characteristics are locally derived by the computing node ! > > I don't think that I agree that we're assuming that a node must > communicate a lot of factors to other nodes. I can imagine something > like AODV, but where each node adds its own hop cost. Depending on > shared network parameters, each node might add e.g. 1/(remaining > lifetime) to the total route cost, or it might add it's link-latency to > the route cost. I'm not advocating something AODV-like, just pointing > out that we don't necessarily need to be propagating a lot of state > information around the network, and potentially complicated (and > platform dependent) local computations can still be done without the > global algorithm needing to know the details. Absolutely. JP. > > ksjp > > Philip Levis wrote: >> >> On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote: >> >>> Jerry touches a point I forgot to mention in relation to Kris' >>> previous postings. >>> >>> I fully support the idea of preferred routers running on battery. >>> We definitely also see this application in the home control domain. >>> >>>> ...let's say I have a battery powered repeater installed in a >>> sparse portion of the mesh. This device has no other meaning in >>>> life but to route messages. Rerouting around this device saves the >>> energy on a device that has no reason to save energy. >>>> Also, remember this repeater was strategically placed to 'fill-in' >>> the mesh. >>> >>> In order to attract interest from the routing protocol, such a node >>> should be able to signal "mains powered" or even better: >>> "I have plenty of battery". >>> Obviously, it should lower that indication to normal >>> "battery-powered" if running close to low; ending with "battery low". >>> br. Anders >>> >>> >>> >> >> I'm confused by this line of logic. Whether a node advertises itself >> as having lots of energy is less important than the available energy >> along a route. I.e., if the next hop, node A, has lots of energy but >> its next hop, node B, is very limited, the fact that A has lots of >> energy is not particularly useful. >> >> So far, this discussion has assumed that a node must communicate a lot >> of factors to other nodes, so they can apply their own algorithms to >> decide which next hop to take. The issue here is that it assumes the >> optimization criteria are the same; even though the router-to-be wants >> to save energy, the sender wants to optimize latency and so ignores >> energy constraints. Another approach is that each node applies its own >> algorithm to determine its willingness/cost, which other nodes then >> take into account. That is, nodes advertise how good a router they >> think they are, and senders take this into consideration. Otherwise, >> especially in a distributed and dynamic system, senders can be making >> decisions based on out-of-date information which is hard to detect >> inconsistencies on without expensive periodic state exchanges. >> >> E.g., one simple way to articulate energy, rather than "I have X" is >> "How expensive I consider sending a packet." This takes into >> consideration a lot more useful information, and is much more flexible >> to compute and consider. >> >> Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 13 02:55:56 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801AE3A687E; Thu, 13 Nov 2008 02:55:56 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585CF3A6868 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 02:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.721 X-Spam-Level: X-Spam-Status: No, score=-5.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_BACKHAIR_11=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY6VVA8he2Iz for <roll@core3.amsl.com>; Thu, 13 Nov 2008 02:55:53 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0E29A3A687E for <roll@ietf.org>; Thu, 13 Nov 2008 02:55:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,596,1220227200"; d="scan'208";a="27682562" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2008 10:55:53 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mADAtriE017336; Thu, 13 Nov 2008 05:55:53 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mADAtqk1004847; Thu, 13 Nov 2008 10:55:53 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 05:55:31 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Nov 2008 10:53:03 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Thu, 13 Nov 2008 11:53:02 +0100 From: JP Vasseur <jvasseur@cisco.com> To: Kris Pister <pister@eecs.berkeley.edu>, <Jerald.P.Martocci@jci.com> Message-ID: <C541C59E.5DCF4%jvasseur@cisco.com> Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclFff+043kZCYrONk6BMIR2tVIiDA== In-Reply-To: <4918C426.8040002@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 13 Nov 2008 10:55:31.0085 (UTC) FILETIME=[5890CBD0:01C9457E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14807; t=1226573753; x=1227437753; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Kris=20Pister=20<pister@eecs.berkeley.edu>,=20<Jeral d.P.Martocci@jci.com>; bh=XdQbUXcYVC7oQIYhV5MZL3nahPJQavsoHK/G82oQwMA=; b=HZKgVzPrj5D7vbjNaR1UOFOZ4b1K5AZPj7gS9McJdvAYHUz/QCD+KPIMzv 8BA24OO/QwKRTTFz7qWFL7zQwE0nQPOk+xx3iIzXHs/BYTor5WynEVw9DvuC Xh0QwaSlz9; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ROLL WG <roll@ietf.org>, Ted.Humpal@jci.com Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi See in line, On 11/11/08 12:30 AM, "Kris Pister" <pister@eecs.berkeley.edu> wrote: > Jerry - powered routing infrastructure is great if you can afford it. > For applications which can't, then battery powered routers are a must. > Whether these use the venerable Low Power Listen approach, or the > upstart Time Synchronized Mesh approach, you get sub-second latency and > power consumption that is in the tens of uA. You're right that I'm > representing the interests of the synchronous network community - that's > what industrial automation is using today, with Wireless HART (shipping) > and ISA100.11a (in draft). > If you only use powered routers, then I agree that the whole > energy-reporting thing is of little interest. > The requirement for industrial is that we be able to do power-aware and > latency-sensitive routing though. Right. The routing MUST thus support this metric, which does not mean that in a specific scenario like building automation, each node would have to use that metrics of course. More below, > > ksjp > > Jerald.P.Martocci@jci.com wrote: >> >> Kris, >> >> I'm getting your point, to a point... >> >> First off, in the Commercial Building market, all routering devices >> will be lines powered and hence the routing protocol need not concern >> itself with power starved routers. You must be vying for some sort of >> synchronous network where the routers power up on a very short duty >> cycle. Our radios typically require 10000x more energy (~27ma) when >> powered up and transmitting or receiving than asleep (2uA). You >> would blow out the joules of any reasonably sized battery quite >> quickly if the receiver needed to be on for extended periods on the >> off-chance that a message needed to be routered through it. >> >> As for the routing protocol needing a priori knowledge of the battery >> status of a device to determine selected paths, I still don't see this >> as a network routing parameter. The node that becomes energy starved >> simply needs to stop forwarding routed messages. The transport will >> quickly notice that messages are not reaching their destination and >> advertise for a new path to which our energy starved device won't >> respond. A more graceful approach would be for the energy starved >> node to simply tell the source node that it is temporarily out of the >> routering business. This functionality needs to be in place anyway >> since even in normal operation, an existing path might get blocked. >> Yes but by anticipating this low energy state, you can better balance the traffic and thus increase the network life duration. >> By advertising remaining energy throughout the network and making >> systemic routing choices based on available energy seems like a nice >> thing to do and would tend to balance the total available energy >> across the mesh. Yes. However, the network also must understand the >> application running on the node to make the choice. For example, >> let's say I have a battery powered repeater installed in a sparse >> portion of the mesh. This device has no other meaning in life but to >> route messages. Rerouting around this device saves the energy on a >> device that has no reason to save energy. Also, remember this >> repeater was strategically placed to 'fill-in' the mesh. By taking it >> out of the mesh routes, all the other nodes will need to use up more >> of their available energy to make up for this missing node. >> Well in that case you may want to have another attribute (preference) and use it in combination with the energy using hierarchical rules when you compute the path. >> Conversely, (kind of!!!) let's say I have a sensor that needs to >> report status temporally. Even if I stop routing, I still need to >> awaken to do my own task on a periodic basis. In many cases I can >> synchronize my application with the duty cycle of the network. Now I >> can continue to perform both jobs without reducing energy any more >> than I would performing my one required job. Right but you would avoid to drain energy from your battery to route others' packets. >> >> My point being that it is important to understand the application >> requirements as well as battery status to make judicious routing >> decisions. Why not let each device decide no its own if it can save >> power by taking itself out of the routing paths. The mesh would then >> just re-form as needed around the devices. The decision on how to use the flag is local to the node. Thanks. JP. >> >> Jerry >> >> >> >> >> *Kris Pister <pister@eecs.berkeley.edu>* >> >> 11/05/2008 10:08 PM >> >> >> To >> Jerald.P.Martocci@jci.com >> cc >> ROLL WG <roll@ietf.org> >> Subject >> Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> >> >> >> >> >> >> >> >> >> Jerry - I'm not trying to get the IETF decide the threshold for any >> flags. My point is that a single bit flag is virtually useless for >> making intelligent routing decisions, regardless of what threshold value >> you choose for it. >> >> You say that remaining energy is not a function of time, and yet the >> units you use to describe where you set the threshold are "months" :) >> Somehow we have to make the same kind of translations between Joules and >> months, and for networks where the routers are battery powered, this IS >> a routing issue. >> >> Here's why: ignoring energy in routing decisions, protocol X creates >> networks that have a distribution of lifetimes varying, for example, >> from three to fifteen years. Protocol Y, using energy in its routing >> decisions, builds networks that have the same mean lifetime, but a >> distribution that is much tighter - from 9 to 12 years. Which one would >> you rather buy? One where you start replacing batteries after 3 years, >> or one were you replace them all at 9 years? >> >> ksjp >> >> Jerald.P.Martocci@jci.com wrote: >>> >>> Why is the IETF trying to establish when the energy flag needs to be >>> set for low battery? This is an application issue. >>> >>> Remaining energy is not a function of time, it's a function of >>> remaining energy. In our current wireless products, we have a >>> comparator that will shut the sensor down at a given voltage level. >>> We have actually calculated the number of joules required per >>> transaction and have back calculated the voltage level at which point >>> we will issue a low-battery alarm. We set the voltage level to alarm >>> about 3 months before the device shuts down, giving the customer 3 >>> months to change the battery. This is for a device that transmits >>> once a minute for about 3 msecs. The battery status is included >>> (1-bit). with every transaction. Two alkaline 'c' cells will last >>> about 10 years, but due to shelf life, we specify 5 year battery life. >>> >>> From my viewpoint all battery powered wireless devices need to >>> transmit their battery status. For interoperability purposes, this >>> should be dictated. However, this is not a protocol issue, much less >>> a routing issue. This should be something done by the implementers or >>> specified at the alliance level (e.g. IPSO). >>> >>> Jerry >>> >>> >>> >>> >>> >>> *Kris Pister <pister@eecs.berkeley.edu>* >>> Sent by: roll-bounces@ietf.org >>> >>> 11/04/2008 06:06 PM >>> >>> >>> To >>> JP Vasseur <jvasseur@cisco.com> >>> cc >>> ROLL WG <roll@ietf.org> >>> Subject >>> Re: [Roll] ROLL Routing Metrics - WF feed-back needed >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Well, we both agree that there will be load imbalance and differential >>> rate of energy consumption, >>> and we both agree that oscillations will be bad. I think that we may >>> have a different picture of the >>> frequency of those oscillations, though. I think that most/all of the >>> systems described in the >>> requirements docs have battery lifetime requirements measured in >>> years. This implies a minimum >>> update rate of, oh, something like monthly. Sending a few tens of >>> bytes of data describing >>> energy and power state on a daily basis is both far more frequent than >>> we need, and unlikely >>> to cause *wasteful* oscillations. If there is some route bouncing >>> with a one day or week period, maybe >>> that's actually optimal. It's certainly not expensive. >>> >>> I'm still very curious as to where you think that we should set the >>> "low energy" flag level. Based on the two scenarios that I presented, >>> I don't see that single-bit flags have much value. As you pointed out >>> in your response, the traffic will not be balanced. Either I set the >>> flag near midpoint, and it doesn't help much, or I set well below >>> midpoint, and it doesn't help very much. >>> >>> I can imagine scenarios in which it works great. Unfortunately, >>> working well 50% of the time doesn't do us much good. We don't have >>> to handle every situation, but we have to at least deal with common >>> problems that come up in real networks. >>> >>> ksjp >>> >>> JP Vasseur wrote: >>> Hi Kris, >>> >>> >>> On 11/4/08 6:28 AM, "Kris Pister" _<pister@eecs.berkeley.edu>_ >>> <mailto:pister@eecs.berkeley.edu> wrote: >>> >>> >>> JP - I'd like to understand more about your flags. >>> If I have a network in which I expect that all motes last for 7 years, >>> where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 >>> years)? At 5% (ideally 3 months)? >>> In the first case, for roughly half of my network lifetime, all of my >>> network will have set the "I'm low on energy" flag, and I will have no >>> useful information with which to make routing decisions. >>> In the second case, I have almost no useful information until it's too >>> late - one year into operation and several of the busiest motes are >>> almost dead, while a mote with a much bigger battery still has almost >>> all of it's charge. So in this case the information shows up too late >>> to be useful. >>> I'm sure that's not the way you see it. What am I missing? >>> >>> >>> >>> See it as a trade-off between frequent accurate updates (=> requiring >>> energy, risk of routing oscillations, ...) and no information at all. >>> If you >>> make the assumption of uniform energy consumption, then flags are always >>> useless (so does more up to date data). On the other hand if you see >>> the use >>> of such flags as safeguard mechanisms, this could be useful to start >>> rerouting the traffic around nodes running out of battery. Suppose >>> that the >>> traffic is not equally balanced in the network, you may end up with >> nodes >>> consuming battery at a much higher rates than others, in which case the >>> flags may be useful, with no risk of oscillation. >>> >>> Thoughts ? >>> >>> Cheers, >>> >>> JP. >>> >>> >>> ksjp >>> >>> JP Vasseur wrote: >>> >>> Hi Miguel, >>> >>> >>> On 10/31/08 12:24 PM, "Miguel Sanchez" _<misan@disca.upv.es>_ >>> <mailto:misan@disca.upv.es> wrote: >>> >>> >>> >>> Hi JP, >>> >>> >>> >>> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur _<jvasseur@cisco.com>_ >>> <mailto:jvasseur@cisco.com> wrote: >>> >>> >>> Hi Kris, >>> >>> >>> On 10/30/08 5:33 PM, "Kris Pister" _<pister@eecs.berkeley.edu>_ >>> <mailto:pister@eecs.berkeley.edu> wrote: >>> >>> I agree with Miguel that we need a standard way of energy reporting, >> and I >>> agree with JP that it's hard to do. >>> Part of the challenge is that energy sources and storage vary so >> much. We >>> have: >>> * line power - great if you can get it! >>> * battery storage >>> - this is time varying. The available energy in a battery is a >>> strong >>> function of the temperature and the usage profile. So a battery powered >>> mote may correctly calculate five years of lifetime in summer, and then >>> that >>> winter under the exact same load conditions it may correctly calculate a >>> lifetime of ten years. The same mote with the same battery may have >>> better >>> performance in summer at higher loads. >>> >>> JP> and usage profile may also change. >>> >>> * capacitive storage >>> * energy scavenging >>> - this is time varying, and tough to bound (usefully >>> >>> JP> this is why I'm questioning the usefulness of knowing the remaining >>> energy expressed in Joules or other metrics. Knowing this value will not >>> tell you anything as to whether you should or should not use that node >>> when >>> computing the path. Another metric may be the remaining estimated >> lifetime >>> >>> >>> I disagree. >>> >>> At least if remaining energy is infinitum (mains powered) tells you >>> something. >>> >>> OTOH, if limited, depending on other properties of the nodes (like >>> where it gets its energy from) it is also useful for making routing >>> decisions too. >>> >>> >>> OK let's try to step back. I'm proposing a flag-based mechanism to >>> avoid the >>> use of a node should this node run out of energy. The decision to >> set the >>> flag is made by the node (no specified) according to many parameters >>> (estimated like time, ... Etc). Some nodes having more power may make >>> use of >>> complex models. >>> >>> If you advertise your remaining power in Joules, how would you >> expect the >>> nodes to change their routing decisions since they have no idea of >> whether >>> you are running low in energy (it highly depends on what the node >>> does, the >>> external conditions, ... Etc) ? >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>> but still, is the node capable (without consuming too much energy) of >>> gathering historical data etc ... to provide an accurate value >> hoping that >>> other criterion such as usage profile or temperature as you pointed out >>> will >>> not change ? >>> >>> All of this makes energy/power/lifetime reporting painful, yet I can not >>> picture a successful routing protocol that doesn't somehow take these >>> factors into account. >>> >>> >>> >>> Kind regards, >>> >>> Miguel >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 13 02:59:35 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94473A688F; Thu, 13 Nov 2008 02:59:35 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67A03A687E for <roll@core3.amsl.com>; Thu, 13 Nov 2008 02:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzRUQ2DmY3q8 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 02:59:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C8B93A6807 for <roll@ietf.org>; Thu, 13 Nov 2008 02:59:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,596,1220227200"; d="scan'208";a="27682704" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2008 10:59:33 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mADAxXwn031446; Thu, 13 Nov 2008 05:59:33 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mADAxXgj005432; Thu, 13 Nov 2008 10:59:33 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 05:59:33 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Nov 2008 10:59:24 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Thu, 13 Nov 2008 11:59:22 +0100 From: JP Vasseur <jvasseur@cisco.com> To: Omprakash Gnawali <gnawali@usc.edu>, Tim Winter <tim.winter@ekasystems.com> Message-ID: <C541C71A.5DCF9%jvasseur@cisco.com> Thread-Topic: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) Thread-Index: AclFfuIz4n6lQ3MCVkGuFKmvsugR7w== In-Reply-To: <d4dcddd20811121847y38cbfc63l9b46d59e9594b3b0@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 13 Nov 2008 10:59:33.0567 (UTC) FILETIME=[E9189CF0:01C9457E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1751; t=1226573973; x=1227437973; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20aggregation=20(Re=3A=20ROLL=20 Routing=20Metrics=20-=20WF=20feed-back=0A=20needed) |Sender:=20 |To:=20Omprakash=20Gnawali=20<gnawali@usc.edu>,=0A=20=20=20 =20=20=20=20=20Tim=20Winter=20<tim.winter@ekasystems.com>; bh=GlQaxYkR+9xafQCrieFikvUzPaDAJDzhSrEZ8SWLnms=; b=Zkcst7xP+EdVbf9Ml/pv+h/lqF4EqKsZC1+5mNdyYx08n7wJXhyMygsEHI 2WAOAOWUCt/cTg4e9uN7uDLvHfLwOEyesxCjR8lyAhxSSqJtMkZp4WuPSj/V 6MF7NaCs+U; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org It could be a bit but for the moment let's agree on whether or not we need it. Personally I would say "yes", others say "No", others say "Yes". I guess that we have a better consensus toward the yes. The immediate next step is to discuss the encoding .. Could be a single bit with optional TLV to carry more data. TO be discussed soon. Cheers, JP. On 11/13/08 3:47 AM, "Omprakash Gnawali" <gnawali@usc.edu> wrote: > On Wed, Nov 12, 2008 at 3:38 PM, Tim Winter <tim.winter@ekasystems.com> wrote: >> One useful application of aggregation would be in an electricity >> metering scenario when a power outage occurs. In this application many >> (previously powered) nodes may find themselves running on a `last gasp' >> power source such as a capacitor. The goal would be allow as many >> sensors as possible to relay their outage status before the last gasp >> source is exhausted, so that a utility can better pinpoint the region >> affected by the outage. >> In this scenario, being able to apply a routing strategy to forward data >> toward nodes capable of aggregation may allow the network to relay much >> more outage information before backup power is exhausted. >> >> -Tim >> > > What does the proposed aggregation metric look like? Is it a bit? Is > this metric different from some combination of "resource" metric such > as CPU, RAM, storage, energy? Yes, in theory but in practice there is > probably no difference. If a packet arrives at a node with gigabytes > of storage or uses wall power, it probably does not matter if the data > is aggregated. > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 13 03:02:37 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346513A6856; Thu, 13 Nov 2008 03:02:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE463A6856 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 03:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.764 X-Spam-Level: X-Spam-Status: No, score=-5.764 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_BACKHAIR_11=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFUJIq1OJFuP for <roll@core3.amsl.com>; Thu, 13 Nov 2008 03:02:35 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A97C83A6807 for <roll@ietf.org>; Thu, 13 Nov 2008 03:02:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,596,1220227200"; d="scan'208";a="27682951" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2008 11:02:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mADB2YbK032653; Thu, 13 Nov 2008 06:02:34 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mADB2Ylo017956; Thu, 13 Nov 2008 11:02:34 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 06:02:34 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Nov 2008 11:02:08 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Thu, 13 Nov 2008 12:02:07 +0100 From: JP Vasseur <jvasseur@cisco.com> To: Kris Pister <pister@eecs.berkeley.edu>, <Jerald.P.Martocci@jci.com> Message-ID: <C541C7BF.5DCFC%jvasseur@cisco.com> Thread-Topic: [Roll] ROLL Routing Metrics - WF feed-back needed Thread-Index: AclFf0SMYUPF5NuWEUm9iqRL1A947A== In-Reply-To: <49126E8D.5030306@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 13 Nov 2008 11:02:34.0563 (UTC) FILETIME=[54FA6930:01C9457F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9711; t=1226574154; x=1227438154; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20 |To:=20Kris=20Pister=20<pister@eecs.berkeley.edu>,=20<Jeral d.P.Martocci@jci.com>; bh=m9kK7uOCbIYe+bMciRuWIicZqN/WOaz4szF9rM6t/o8=; b=Jai8EWLIbeVWQTGy2z83+DJd/F7nqGxezQJsDF95gK99t2Zj0EtUfJW8Lv BdORwP7PhjBrG9ay9wYtKLn9504mtDssrsW3jpV/5dkn74rKHw06WJ+SrlRA 4dZy1/H4qS; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ROLL WG <roll@ietf.org> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Jerry, It *is* a routing issue since you want to change your routing decision according to the remaining energy on "each" node. Thanks. JP. On 11/6/08 5:11 AM, "Kris Pister" <pister@eecs.berkeley.edu> wrote: > Jerry - I'm not trying to get the IETF decide the threshold for any > flags. My point is that a single bit flag is virtually useless for > making intelligent routing decisions, regardless of what threshold value > you choose for it. > > You say that remaining energy is not a function of time, and yet the > units you use to describe where you set the threshold are "months" :) > Somehow we have to make the same kind of translations between Joules and > months, and for networks where the routers are battery powered, this IS > a routing issue. > > Here's why: ignoring energy in routing decisions, protocol X creates > networks that have a distribution of lifetimes varying, for example, > from three to fifteen years. Protocol Y, using energy in its routing > decisions, builds networks that have the same mean lifetime, but a > distribution that is much tighter - from 9 to 12 years. Which one would > you rather buy? One where you start replacing batteries after 3 years, > or one were you replace them all at 9 years? > > ksjp > > Jerald.P.Martocci@jci.com wrote: >> >> Why is the IETF trying to establish when the energy flag needs to be >> set for low battery? This is an application issue. >> >> Remaining energy is not a function of time, it's a function of >> remaining energy. In our current wireless products, we have a >> comparator that will shut the sensor down at a given voltage level. >> We have actually calculated the number of joules required per >> transaction and have back calculated the voltage level at which point >> we will issue a low-battery alarm. We set the voltage level to alarm >> about 3 months before the device shuts down, giving the customer 3 >> months to change the battery. This is for a device that transmits >> once a minute for about 3 msecs. The battery status is included >> (1-bit). with every transaction. Two alkaline 'c' cells will last >> about 10 years, but due to shelf life, we specify 5 year battery life. >> >> From my viewpoint all battery powered wireless devices need to >> transmit their battery status. For interoperability purposes, this >> should be dictated. However, this is not a protocol issue, much less >> a routing issue. This should be something done by the implementers or >> specified at the alliance level (e.g. IPSO). >> >> Jerry >> >> >> >> >> >> *Kris Pister <pister@eecs.berkeley.edu>* >> Sent by: roll-bounces@ietf.org >> >> 11/04/2008 06:06 PM >> >> >> To >> JP Vasseur <jvasseur@cisco.com> >> cc >> ROLL WG <roll@ietf.org> >> Subject >> Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> >> >> >> >> >> >> >> >> >> Well, we both agree that there will be load imbalance and differential >> rate of energy consumption, >> and we both agree that oscillations will be bad. I think that we may >> have a different picture of the >> frequency of those oscillations, though. I think that most/all of the >> systems described in the >> requirements docs have battery lifetime requirements measured in >> years. This implies a minimum >> update rate of, oh, something like monthly. Sending a few tens of >> bytes of data describing >> energy and power state on a daily basis is both far more frequent than >> we need, and unlikely >> to cause *wasteful* oscillations. If there is some route bouncing >> with a one day or week period, maybe >> that's actually optimal. It's certainly not expensive. >> >> I'm still very curious as to where you think that we should set the >> "low energy" flag level. Based on the two scenarios that I presented, >> I don't see that single-bit flags have much value. As you pointed out >> in your response, the traffic will not be balanced. Either I set the >> flag near midpoint, and it doesn't help much, or I set well below >> midpoint, and it doesn't help very much. >> >> I can imagine scenarios in which it works great. Unfortunately, >> working well 50% of the time doesn't do us much good. We don't have >> to handle every situation, but we have to at least deal with common >> problems that come up in real networks. >> >> ksjp >> >> JP Vasseur wrote: >> Hi Kris, >> >> >> On 11/4/08 6:28 AM, "Kris Pister" _<pister@eecs.berkeley.edu>_ >> <mailto:pister@eecs.berkeley.edu> wrote: >> >> >> JP - I'd like to understand more about your flags. >> If I have a network in which I expect that all motes last for 7 years, >> where do I set the "I'm low on energy" flag? At 50% (ideally 3.5 >> years)? At 5% (ideally 3 months)? >> In the first case, for roughly half of my network lifetime, all of my >> network will have set the "I'm low on energy" flag, and I will have no >> useful information with which to make routing decisions. >> In the second case, I have almost no useful information until it's too >> late - one year into operation and several of the busiest motes are >> almost dead, while a mote with a much bigger battery still has almost >> all of it's charge. So in this case the information shows up too late >> to be useful. >> I'm sure that's not the way you see it. What am I missing? >> >> >> >> See it as a trade-off between frequent accurate updates (=> requiring >> energy, risk of routing oscillations, ...) and no information at all. >> If you >> make the assumption of uniform energy consumption, then flags are always >> useless (so does more up to date data). On the other hand if you see >> the use >> of such flags as safeguard mechanisms, this could be useful to start >> rerouting the traffic around nodes running out of battery. Suppose >> that the >> traffic is not equally balanced in the network, you may end up with nodes >> consuming battery at a much higher rates than others, in which case the >> flags may be useful, with no risk of oscillation. >> >> Thoughts ? >> >> Cheers, >> >> JP. >> >> >> ksjp >> >> JP Vasseur wrote: >> >> Hi Miguel, >> >> >> On 10/31/08 12:24 PM, "Miguel Sanchez" _<misan@disca.upv.es>_ >> <mailto:misan@disca.upv.es> wrote: >> >> >> >> Hi JP, >> >> >> >> On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur _<jvasseur@cisco.com>_ >> <mailto:jvasseur@cisco.com> wrote: >> >> >> Hi Kris, >> >> >> On 10/30/08 5:33 PM, "Kris Pister" _<pister@eecs.berkeley.edu>_ >> <mailto:pister@eecs.berkeley.edu> wrote: >> >> I agree with Miguel that we need a standard way of energy reporting, and I >> agree with JP that it's hard to do. >> Part of the challenge is that energy sources and storage vary so much. We >> have: >> * line power - great if you can get it! >> * battery storage >> - this is time varying. The available energy in a battery is a >> strong >> function of the temperature and the usage profile. So a battery powered >> mote may correctly calculate five years of lifetime in summer, and then >> that >> winter under the exact same load conditions it may correctly calculate a >> lifetime of ten years. The same mote with the same battery may have >> better >> performance in summer at higher loads. >> >> JP> and usage profile may also change. >> >> * capacitive storage >> * energy scavenging >> - this is time varying, and tough to bound (usefully >> >> JP> this is why I'm questioning the usefulness of knowing the remaining >> energy expressed in Joules or other metrics. Knowing this value will not >> tell you anything as to whether you should or should not use that node >> when >> computing the path. Another metric may be the remaining estimated lifetime >> >> >> I disagree. >> >> At least if remaining energy is infinitum (mains powered) tells you >> something. >> >> OTOH, if limited, depending on other properties of the nodes (like >> where it gets its energy from) it is also useful for making routing >> decisions too. >> >> >> OK let's try to step back. I'm proposing a flag-based mechanism to >> avoid the >> use of a node should this node run out of energy. The decision to set the >> flag is made by the node (no specified) according to many parameters >> (estimated like time, ... Etc). Some nodes having more power may make >> use of >> complex models. >> >> If you advertise your remaining power in Joules, how would you expect the >> nodes to change their routing decisions since they have no idea of whether >> you are running low in energy (it highly depends on what the node >> does, the >> external conditions, ... Etc) ? >> >> Thanks. >> >> JP. >> >> >> >> but still, is the node capable (without consuming too much energy) of >> gathering historical data etc ... to provide an accurate value hoping that >> other criterion such as usage profile or temperature as you pointed out >> will >> not change ? >> >> All of this makes energy/power/lifetime reporting painful, yet I can not >> picture a successful routing protocol that doesn't somehow take these >> factors into account. >> >> >> >> Kind regards, >> >> Miguel >> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 13 06:39:19 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42DF53A6987; Thu, 13 Nov 2008 06:39:19 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DA23A6987 for <roll@core3.amsl.com>; Thu, 13 Nov 2008 06:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48Cn75kxjB2W for <roll@core3.amsl.com>; Thu, 13 Nov 2008 06:39:18 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id EF8EF3A695B for <roll@ietf.org>; Thu, 13 Nov 2008 06:39:17 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so672512yxg.49 for <roll@ietf.org>; Thu, 13 Nov 2008 06:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xaJU3NQdXbkNNUTxGXoBUye68P2yl8WtWnMZdSV2aJA=; b=fCHrakh2KNagcoTemf2PmuZ8Fn22TBC/ICCzG8htXE1ix+0+Or/PxkpCHbQbIktv1r eYe3ohwWUVzKonFTipgkPEFtmonsnrybWB9di3XBBKaBSwOr67I4lk4OVVtM6ofZRelm MyyHO/Fawuk6QH8U/DBamT/wOqJbj1YHeGYjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=N1cxLvU9rzyPPfwNBHw+WzJfgq+DXSeFsKquGHKVqjFkc/pbmN3c88fO6iiOkYAIKl TjwSxZ1SGdsJ+GG3Zk06osOB6uS5O0tHSjZnIj57LUdnr6tHjy1fE0MKtcJwvAxAgBaJ zhjTazCa3DTJC9vrlGogRUSWWvZKHd/U97XyM= Received: by 10.90.71.15 with SMTP id t15mr9141537aga.90.1226586554506; Thu, 13 Nov 2008 06:29:14 -0800 (PST) Received: by 10.90.102.19 with HTTP; Thu, 13 Nov 2008 06:29:14 -0800 (PST) Message-ID: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> Date: Thu, 13 Nov 2008 06:29:14 -0800 From: "Omprakash Gnawali" <gnawali@usc.edu> To: "JP Vasseur" <jvasseur@cisco.com> In-Reply-To: <C541C71A.5DCF9%jvasseur@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <d4dcddd20811121847y38cbfc63l9b46d59e9594b3b0@mail.gmail.com> <C541C71A.5DCF9%jvasseur@cisco.com> X-Google-Sender-Auth: 5753e6e939745336 Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Thu, Nov 13, 2008 at 2:59 AM, JP Vasseur <jvasseur@cisco.com> wrote: > It could be a bit but for the moment let's agree on whether or not we need > it. Personally I would say "yes", others say "No", others say "Yes". I guess > that we have a better consensus toward the yes. I had the impression that there was no consensus at this point. I still don't understand the difference between CPU/RAM/storage/Energy metric and aggregation metric in practice. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Nov 14 00:26:04 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EAD3A6A40; Fri, 14 Nov 2008 00:26:04 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099013A6A40 for <roll@core3.amsl.com>; Fri, 14 Nov 2008 00:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31mLN4EFiSjk for <roll@core3.amsl.com>; Fri, 14 Nov 2008 00:26:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1682A3A6898 for <roll@ietf.org>; Fri, 14 Nov 2008 00:26:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,602,1220227200"; d="scan'208";a="27837540" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Nov 2008 08:26:01 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAE8Q0cK011542; Fri, 14 Nov 2008 03:26:00 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAE8Q0jG018891; Fri, 14 Nov 2008 08:26:00 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 03:26:00 -0500 Received: from 10.55.201.133 ([10.55.201.133]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Nov 2008 08:25:43 +0000 User-Agent: Microsoft-Entourage/12.13.0.080930 Date: Fri, 14 Nov 2008 09:25:42 +0100 From: JP Vasseur <jvasseur@cisco.com> To: Omprakash Gnawali <gnawali@usc.edu> Message-ID: <C542F496.5DD95%jvasseur@cisco.com> Thread-Topic: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) Thread-Index: AclGMpURg/TvjuV6WUWTL1wL4vqdOw== In-Reply-To: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 14 Nov 2008 08:26:00.0799 (UTC) FILETIME=[A04586F0:01C94632] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=933; t=1226651161; x=1227515161; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[Roll]=20aggregation=20(Re=3A=20ROLL=20 Routing=20Metrics=20-=20WF=20feed-back=0A=20needed) |Sender:=20 |To:=20Omprakash=20Gnawali=20<gnawali@usc.edu>; bh=seqzAo/h8wgNB4F8mUbzzMvoci2jkv0fWHSAhVY50No=; b=PmiAk/CnbWuKVW3Rcraehbxk6SI+ZT2RRdtddqxf12kPZfUoCz3yq/He+U rfrEU0W6HauI5JLO1vhXsmpEjM8PDyis8A0NYtoLKaHWd3UntmGL4lN+MuOd 3YEVv2MxDy; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 11/13/08 3:29 PM, "Omprakash Gnawali" <gnawali@usc.edu> wrote: > On Thu, Nov 13, 2008 at 2:59 AM, JP Vasseur <jvasseur@cisco.com> wrote: >> It could be a bit but for the moment let's agree on whether or not we need >> it. Personally I would say "yes", others say "No", others say "Yes". I guess >> that we have a better consensus toward the yes. > > I had the impression that there was no consensus at this point. > > I still don't understand the difference between CPU/RAM/storage/Energy > metric and aggregation metric in practice. > Both are used for routing of course but the aggregation metric is used to change the routing decision so as to allow for data aggregation (there could be multiple data depending on the type of aggregated data); the CPU/RAM or Energy are used to change the routing decision so as to compute the shortest *constrained* path. Hope this helps. JP. > - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Nov 14 14:33:53 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9F83A6932; Fri, 14 Nov 2008 14:33:53 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554CE3A6932 for <roll@core3.amsl.com>; Fri, 14 Nov 2008 14:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.767 X-Spam-Level: X-Spam-Status: No, score=-9.767 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhS7O0lrZZBd for <roll@core3.amsl.com>; Fri, 14 Nov 2008 14:33:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E7D003A68F3 for <roll@ietf.org>; Fri, 14 Nov 2008 14:33:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,606,1220227200"; d="scan'208";a="25725301" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Nov 2008 22:33:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAEMXi0G011190 for <roll@ietf.org>; Fri, 14 Nov 2008 23:33:44 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAEMXiGu005531 for <roll@ietf.org>; Fri, 14 Nov 2008 22:33:44 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 23:33:44 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Nov 2008 23:33:44 +0100 Message-Id: <0D117803-844F-4058-B582-29A4A1762761@cisco.com> From: JP Vasseur <jvasseur@cisco.com> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 14 Nov 2008 23:33:44 +0100 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 14 Nov 2008 22:33:44.0288 (UTC) FILETIME=[0D460600:01C946A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=124; t=1226702024; x=1227566024; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Slides=20Please |Sender:=20; bh=0rzqNbz6PQWCcXGcHLe1X4NyByv2lGg98Skx27tBtJs=; b=XpPdLRuVj9UFmeDnOoXt0f12YSph/TyvBwaqrMBruLgxmdP1XA5G3ffrQg KtaMDfAYX0PA3ehs2fPqrvoZmGj8sESUEzCtb5CVvg8GSCc/5ReE2qRde2ff 9yrebPQivf; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] Slides Please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear all, If you have a slot at the ROLL WG Meeting next week, thanks to send your slides *today*. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Nov 14 15:09:48 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5333A6AA4; Fri, 14 Nov 2008 15:09:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895C93A6AA6 for <roll@core3.amsl.com>; Fri, 14 Nov 2008 15:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1prAa+V2smq for <roll@core3.amsl.com>; Fri, 14 Nov 2008 15:09:46 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 7472E3A6AA0 for <roll@ietf.org>; Fri, 14 Nov 2008 15:09:45 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so1098297ywj.49 for <roll@ietf.org>; Fri, 14 Nov 2008 15:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Llz8qhw2b3jlc9438qzniSvDEQJlm0zNLwdviz3Jkos=; b=l3JsEkOGYVafPP6YoQbleK5WjDAqfErmbNvXPbrUV1HUX6NJWHr0IhYZCcAijhNuRb zOhdVhI3iJ7zZidNJHJJn7+8Q2Y4O3K0OHfs7evjeZ6Uvt8MEV1q0XeWeYuj+TIc191V JNt1CRPakOQ9um8DV/4OtjSu7hAmgqTxYh7qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=DmLI+hktDkymygiVIkQ6jf9JiFHsqXWHBJMZTowR7MJRkEKhhClCFbFWizAtXbyiD0 Fk9Jjrz6fTY7UweZ1JEhttX32vJT9KACS+i+OgsgTadqGHkXfkcME7wIy2gyp9NvnUx5 Xo/7Y10DQEj0At5YmEhNjZIm5W+alCzBPGk9A= Received: by 10.90.89.18 with SMTP id m18mr1159165agb.2.1226704185600; Fri, 14 Nov 2008 15:09:45 -0800 (PST) Received: by 10.90.102.19 with HTTP; Fri, 14 Nov 2008 15:09:45 -0800 (PST) Message-ID: <d4dcddd20811141509h248722b6h7feacc5947bc3068@mail.gmail.com> Date: Fri, 14 Nov 2008 15:09:45 -0800 From: "Omprakash Gnawali" <gnawali@usc.edu> To: "JP Vasseur" <jvasseur@cisco.com> In-Reply-To: <C542F496.5DD95%jvasseur@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> <C542F496.5DD95%jvasseur@cisco.com> X-Google-Sender-Auth: a27469d08c6c9be4 Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Fri, Nov 14, 2008 at 12:25 AM, JP Vasseur <jvasseur@cisco.com> wrote: > Hi, > > > On 11/13/08 3:29 PM, "Omprakash Gnawali" <gnawali@usc.edu> wrote: > >> On Thu, Nov 13, 2008 at 2:59 AM, JP Vasseur <jvasseur@cisco.com> wrote: >>> It could be a bit but for the moment let's agree on whether or not we need >>> it. Personally I would say "yes", others say "No", others say "Yes". I guess >>> that we have a better consensus toward the yes. >> >> I had the impression that there was no consensus at this point. >> >> I still don't understand the difference between CPU/RAM/storage/Energy >> metric and aggregation metric in practice. >> > > Both are used for routing of course but the aggregation metric is used to > change the routing decision so as to allow for data aggregation (there could > be multiple data depending on the type of aggregated data); the CPU/RAM or > Energy are used to change the routing decision so as to compute the shortest > *constrained* path. > Thanks. Because this is a metric that reflects software feature of a node, should there be metrics such as compression, FFT, and things like that? For aggregation to be possible, we need a forwarding architecture that allows execution of application specific processing code in between packet reception and transmission. If there is a commitment to such a architecture, aggregation and many other metrics that expose software capability makes sense. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Nov 14 15:15:17 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27073A6AA7; Fri, 14 Nov 2008 15:15:16 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C1428C13B for <roll@core3.amsl.com>; Fri, 14 Nov 2008 15:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQaxIV3+JUMq for <roll@core3.amsl.com>; Fri, 14 Nov 2008 15:15:15 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2CA783A6AA1 for <roll@ietf.org>; Fri, 14 Nov 2008 15:15:15 -0800 (PST) Received: from [76.14.71.180] (helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1L17sh-00066p-61; Fri, 14 Nov 2008 15:15:15 -0800 Message-Id: <915E9446-9092-40FA-BFE9-6E9D914DFF40@cs.stanford.edu> From: Philip Levis <pal@cs.stanford.edu> To: Omprakash Gnawali <gnawali@usc.edu> In-Reply-To: <d4dcddd20811141509h248722b6h7feacc5947bc3068@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 15:15:14 -0800 References: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> <C542F496.5DD95%jvasseur@cisco.com> <d4dcddd20811141509h248722b6h7feacc5947bc3068@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 8577cc8f8d13cb4ae2b02fc82e253015 Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 14, 2008, at 3:09 PM, Omprakash Gnawali wrote: > On Fri, Nov 14, 2008 at 12:25 AM, JP Vasseur <jvasseur@cisco.com> > wrote: >> Hi, >> >> >> On 11/13/08 3:29 PM, "Omprakash Gnawali" <gnawali@usc.edu> wrote: >> >>> On Thu, Nov 13, 2008 at 2:59 AM, JP Vasseur <jvasseur@cisco.com> >>> wrote: >>>> It could be a bit but for the moment let's agree on whether or >>>> not we need >>>> it. Personally I would say "yes", others say "No", others say >>>> "Yes". I guess >>>> that we have a better consensus toward the yes. >>> >>> I had the impression that there was no consensus at this point. >>> >>> I still don't understand the difference between CPU/RAM/storage/ >>> Energy >>> metric and aggregation metric in practice. >>> >> >> Both are used for routing of course but the aggregation metric is >> used to >> change the routing decision so as to allow for data aggregation >> (there could >> be multiple data depending on the type of aggregated data); the CPU/ >> RAM or >> Energy are used to change the routing decision so as to compute the >> shortest >> *constrained* path. >> > > Thanks. Because this is a metric that reflects software feature of a > node, should there be metrics such as compression, FFT, and things > like that? For aggregation to be possible, we need a forwarding > architecture that allows execution of application specific processing > code in between packet reception and transmission. If there is a > commitment to such a architecture, aggregation and many other metrics > that expose software capability makes sense. From an IP standpoint, aggregation seems problematic. Among other things, it breaks end-to-end, not even in the soft way (addresses) that NATs do, but by actually changing the payload. This seems to me to be a real nightmare scenario. Let's say that the aggregation is something as simple as data suppression; this requires the router, among other things, to know the transport protocol. No matter that data suppression would be an issue for connection-oriented protocols such as TCP or DCCP. Setting up aggregation as a transport-layer overlay seems much more feasible. E.g., nodes send UDP traffic to an aggregation point (could be single hop), which then aggregates the date and sources new, aggregated packets. But this would be a layer 5+ decision, not a layer 3 one. Or am I missing something? Perhaps if I had a better sense of what's meant by "aggregation," e.g., a concrete scenario, this discussion might be more structured. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Nov 16 03:46:46 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602663A67F9; Sun, 16 Nov 2008 03:46:46 -0800 (PST) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B14A33A67F7; Tue, 11 Nov 2008 14:50:49 -0800 (PST) X-idtracker: yes To: IETF-Announce <ietf-announce@ietf.org> From: The IESG <iesg-secretary@ietf.org> Message-Id: <20081111225049.B14A33A67F7@core3.amsl.com> Date: Tue, 11 Nov 2008 14:50:49 -0800 (PST) X-Mailman-Approved-At: Sun, 16 Nov 2008 03:46:45 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: draft-ietf-roll-urban-routing-reqs (Urban WSNs Routing Requirements in Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Urban WSNs Routing Requirements in Low Power and Lossy Networks ' <draft-ietf-roll-urban-routing-reqs-02.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-roll-urban-routing-reqs-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17207&rfc_flag=0 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 17 00:16:14 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0963A69A8; Mon, 17 Nov 2008 00:16:14 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324D73A6979 for <roll@core3.amsl.com>; Mon, 17 Nov 2008 00:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.895 X-Spam-Level: X-Spam-Status: No, score=-94.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLT2DJcOOB5Q for <roll@core3.amsl.com>; Mon, 17 Nov 2008 00:16:12 -0800 (PST) Received: from smfilter2.kt.co.kr (smfilter2.kt.co.kr [147.6.85.168]) by core3.amsl.com (Postfix) with ESMTP id 776DB3A69C1 for <roll@ietf.org>; Mon, 17 Nov 2008 00:15:59 -0800 (PST) Received: from external ([147.6.42.21]) by smfilter2 (1.0) id mAH8FI700BAE; Mon, 17 Nov 2008 17:15:18 +0900 Received: from MAIL06CL ([147.6.42.231]) by smtp01.oasys.kt.co.kr with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Nov 2008 17:16:21 +0900 Received: from mail pickup service by MAIL06CL with Microsoft SMTPSVC; Mon, 17 Nov 2008 17:16:21 +0900 Priority: normal Thread-Index: AclIjMXrMq3pPe9JRhWC9oovODGPFg== Message-ID: <414201c9488c$c5ed62e0$e72a0693@oasys.kt.co.kr> X-AuditID: 93062d73-aa873bb000004cbd-67-49212601d5e7 X-Mailer: Microsoft CDO for Exchange 2000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Importance: normal Content-class: urn:content-classes:message From: =?ks_c_5601-1987?B?sei5zMGhW1VTTr+ssbi047TnXQ==?= <mjkim@kt.com> To: <roll@ietf.org> Cc: MIME-Version: 1.0 Date: Mon, 17 Nov 2008 17:16:20 +0900 X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 17 Nov 2008 08:07:40.0027 (UTC) FILETIME=[8F664CB0:01C9488B] Subject: [Roll] FW: New Version Notification for draft-mjkim-roll-routing-metrics-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: =?ks_c_5601-1987?B?sei5zMGhW1VTTr+ssbi047TnXQ==?= <mjkim@kt.com> List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: multipart/mixed; boundary="===============1317008101==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1317008101== Content-Type: multipart/alternative; boundary="----=_NextPart_000_4143_01C948D8.35D50AE0" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_4143_01C948D8.35D50AE0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ks_c_5601-1987" Dear Roll members, I have just uploaded a new version of routing metric doc. We tried to reflect all comments discussed during last a few weeks over ML. Hope to have more valuable discussion at the IETF meeting. Thank you. JP. Vasseur and Mijeom Kim. -----¿øº» ¸Þ½ÃÁö----- º¸³½ »ç¶÷: "IETF I-D Submission Tool" <idsubmission@ietf.org> º¸³½ ³¯Â¥: 2008-11-17 ¿ÀÈÄ 5:06:24 ¹Þ´Â »ç¶÷: "mjkim@kt.com" <mjkim@kt.com> ÂüÁ¶: "jpv@cisco.com" <jpv@cisco.com>, "hjchong@kt.com" <hjchong@kt.com> Á¦¸ñ: New Version Notification for draft-mjkim-roll-routing-metrics-02 A new version of I-D, draft-mjkim-roll-routing-metrics-02.txt has been successfuly submitted by Mijeom Kim and posted to the IETF repository. Filename: draft-mjkim-roll-routing-metrics Revision: 02 Title: Routing Metrics used for Path Calculation in Low Power and Lossy Networks Creation_date: 2008-11-17 WG ID: Independent Submission Number_of_pages: 13 Abstract: This document specifies routing metrics to be used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link attributes, this document specifies a set of routing metrics suitable to LLNs. The IETF Secretariat. ------=_NextPart_000_4143_01C948D8.35D50AE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGJvZHk+PERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxE SVY+CjxQPiZuYnNwOzwvUD4KPFA+RGVhciBSb2xsIG1lbWJlcnMsPC9QPgo8UD4mbmJzcDs8L1A+ CjxQPkkgaGF2ZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2Ygcm91dGluZyBtZXRyaWMg ZG9jLjwvUD4KPFA+V2UgdHJpZWQgdG8gcmVmbGVjdCBhbGwgY29tbWVudHMgZGlzY3Vzc2VkIGR1 cmluZyBsYXN0IGEgZmV3IHdlZWtzIG92ZXImbmJzcDtNTC48L1A+CjxQPkhvcGUgdG8gaGF2ZSBt b3JlIHZhbHVhYmxlIGRpc2N1c3Npb24mbmJzcDthdCB0aGUgSUVURiBtZWV0aW5nLjwvUD4KPFA+ Jm5ic3A7PC9QPgo8UD5UaGFuayB5b3UuPC9QPgo8UD5KUC4gVmFzc2V1ciBhbmQgTWlqZW9tIEtp bS48L1A+CjxQPiZuYnNwOzwvUD48L0RJVj48L0RJVj4KPERJViBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogsby4siI+CjxESVY+PEJSPi0tLS0tv/i6uyC43r3DwfYtLS0tLTxC Uj48Qj66uLO9ILvntvc6PC9CPiAiSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIiAmbHQ7aWRzdWJt aXNzaW9uQGlldGYub3JnJmd0OzxCUj48Qj66uLO9ILOvwqU6PC9CPiAyMDA4LTExLTE3IL/AyMQg NTowNjoyNDxCUj48Qj653rTCILvntvc6PC9CPiAibWpraW1Aa3QuY29tIiAmbHQ7bWpraW1Aa3Qu Y29tJmd0OzxCUj48Qj7C/MG2OjwvQj4gImpwdkBjaXNjby5jb20iICZsdDtqcHZAY2lzY28uY29t Jmd0OywgImhqY2hvbmdAa3QuY29tIiAmbHQ7aGpjaG9uZ0BrdC5jb20mZ3Q7PEJSPjxCPsGmuPE6 PC9CPiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1qa2ltLXJvbGwtcm91dGlu Zy1tZXRyaWNzLTAyPEJSPjxCUj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0 IC0tPjxCUj4KPFA+PEZPTlQgc2l6ZT0yPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tamtp bS1yb2xsLXJvdXRpbmctbWV0cmljcy0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0 dGVkIGJ5IE1pamVvbSBLaW0gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LjxCUj48 QlI+RmlsZW5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRy YWZ0LW1qa2ltLXJvbGwtcm91dGluZy1tZXRyaWNzPEJSPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMjxCUj5UaXRsZTombmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvdXRpbmcgTWV0cmljcyB1 c2VkIGZvciBQYXRoIENhbGN1bGF0aW9uIGluIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3M8 QlI+Q3JlYXRpb25fZGF0ZTombmJzcDsmbmJzcDsgMjAwOC0xMS0xNzxCUj5XRyBJRDombmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGVwZW5k ZW50IFN1Ym1pc3Npb248QlI+TnVtYmVyX29mX3BhZ2VzOiAxMzxCUj48QlI+QWJzdHJhY3Q6PEJS PlRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHJvdXRpbmcgbWV0cmljcyB0byBiZSB1c2VkIGluIHBh dGg8QlI+Y2FsY3VsYXRpb24gZm9yIFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5l dHdvcmtzIChST0xMKS48QlI+TG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcykgaGF2 ZSB1bmlxdWUgY2hhcmFjdGVyaXN0aWNzPEJSPmNvbXBhcmVkIHdpdGggdHJhZGl0aW9uYWwgd2ly ZWQgbmV0d29ya3Mgb3IgZXZlbiB3aXRoIHNpbWlsYXIgb25lczxCUj5zdWNoIGFzIG1vYmlsZSBh ZC1ob2MgbmV0d29ya3MuJm5ic3A7IEJ5IGNvbnRyYXN0IHdpdGggdHlwaWNhbCBJbnRlcmlvcjxC Uj5HYXRld2F5IFByb3RvY29sIChJR1ApIHJvdXRpbmcgbWV0cmljcyB1c2luZyBob3AgY291bnRz IG9yIGxpbms8QlI+YXR0cmlidXRlcywgdGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzZXQgb2Yg cm91dGluZyBtZXRyaWNzIHN1aXRhYmxlPEJSPnRvIExMTnMuPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxCUj48QlI+PEJSPlRoZSBJRVRGIFNlY3JldGFyaWF0LjxCUj48QlI+PEJS PjwvRk9OVD48L1A+PEJSPjxCUj48L0RJVj48L0RJVj48L2JvZHk+ ------=_NextPart_000_4143_01C948D8.35D50AE0-- --===============1317008101== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1317008101==-- From roll-bounces@ietf.org Mon Nov 17 13:59:04 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CB23A6A6C; Mon, 17 Nov 2008 13:59:04 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764143A6A6C for <roll@core3.amsl.com>; Mon, 17 Nov 2008 13:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyqxOIexhSIM for <roll@core3.amsl.com>; Mon, 17 Nov 2008 13:59:02 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 6929C3A6907 for <roll@ietf.org>; Mon, 17 Nov 2008 13:59:02 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1526103yxg.49 for <roll@ietf.org>; Mon, 17 Nov 2008 13:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=Es7fgbcG++/W75+q74u9wXDJrkqW/IZboqfvda+4ZD0=; b=uKg2l9QllQUZIDUuiAFDyct04MJlsXn2CmjDdbxXRyrNOM6pSpuUSDKDw/npaAyjQ4 VWJtNc45C32BYx7azBxoa0JldwpDBYcZnFy+Gt9jk3kCbhrakg+B7H8bWO/ffmqF44Ij JnM2M28LRmGt+yaw0SzdIUU1fX488hpHHmm0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=bT8Fj8CJCPkRKuOUzwC5f07FbrVwCntV/8rVs3gtbEEV1Qr/GZBjCYLXNfk7vcAemB 0FkZOHqrPDjK8lO3g73Fc9I4HCjEWptRo2cuVsnog89iAG6ImbPKfaczkuLMn4jV0Qw5 UNNM6LsxDpDXR/UijZUwD/CoFjBxPE6BMfvCo= Received: by 10.90.97.18 with SMTP id u18mr2984985agb.106.1226959141626; Mon, 17 Nov 2008 13:59:01 -0800 (PST) Received: by 10.90.102.19 with HTTP; Mon, 17 Nov 2008 13:59:01 -0800 (PST) Message-ID: <d4dcddd20811171359p69c344dei57499bc5766251de@mail.gmail.com> Date: Mon, 17 Nov 2008 13:59:01 -0800 From: "Omprakash Gnawali" <gnawali@usc.edu> To: "Philip Levis" <pal@cs.stanford.edu> In-Reply-To: <915E9446-9092-40FA-BFE9-6E9D914DFF40@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> <C542F496.5DD95%jvasseur@cisco.com> <d4dcddd20811141509h248722b6h7feacc5947bc3068@mail.gmail.com> <915E9446-9092-40FA-BFE9-6E9D914DFF40@cs.stanford.edu> X-Google-Sender-Auth: 50f39876c37b71ce Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Fri, Nov 14, 2008 at 3:15 PM, Philip Levis <pal@cs.stanford.edu> wrote: > > On Nov 14, 2008, at 3:09 PM, Omprakash Gnawali wrote: > >> On Fri, Nov 14, 2008 at 12:25 AM, JP Vasseur <jvasseur@cisco.com> wrote: >>> >>> Hi, >>> >>> >>> On 11/13/08 3:29 PM, "Omprakash Gnawali" <gnawali@usc.edu> wrote: >>> >>>> On Thu, Nov 13, 2008 at 2:59 AM, JP Vasseur <jvasseur@cisco.com> wrote: >>>>> >>>>> It could be a bit but for the moment let's agree on whether or not we >>>>> need >>>>> it. Personally I would say "yes", others say "No", others say "Yes". I >>>>> guess >>>>> that we have a better consensus toward the yes. >>>> >>>> I had the impression that there was no consensus at this point. >>>> >>>> I still don't understand the difference between CPU/RAM/storage/Energy >>>> metric and aggregation metric in practice. >>>> >>> >>> Both are used for routing of course but the aggregation metric is used to >>> change the routing decision so as to allow for data aggregation (there >>> could >>> be multiple data depending on the type of aggregated data); the CPU/RAM >>> or >>> Energy are used to change the routing decision so as to compute the >>> shortest >>> *constrained* path. >>> >> >> Thanks. Because this is a metric that reflects software feature of a >> node, should there be metrics such as compression, FFT, and things >> like that? For aggregation to be possible, we need a forwarding >> architecture that allows execution of application specific processing >> code in between packet reception and transmission. If there is a >> commitment to such a architecture, aggregation and many other metrics >> that expose software capability makes sense. > > From an IP standpoint, aggregation seems problematic. Among other things, it > breaks end-to-end, not even in the soft way (addresses) that NATs do, but by > actually changing the payload. This seems to me to be a real nightmare > scenario. Let's say that the aggregation is something as simple as data > suppression; this requires the router, among other things, to know the > transport protocol. No matter that data suppression would be an issue for > connection-oriented protocols such as TCP or DCCP. > > Setting up aggregation as a transport-layer overlay seems much more > feasible. E.g., nodes send UDP traffic to an aggregation point (could be > single hop), which then aggregates the date and sources new, aggregated > packets. But this would be a layer 5+ decision, not a layer 3 one. > > Or am I missing something? Perhaps if I had a better sense of what's meant > by "aggregation," e.g., a concrete scenario, this discussion might be more > structured. > There is a concrete scenario in the draft. Node A sends the data "xyz" to C. Node B sends the data "xqz" to C. Node C then transmits "xyzq" to the sink. So scenario is not the problem. The problem is ignoring the forwarding implications of it as you clearly articulated. I was surprised that the discussion on this metric was not reflected in the updated draft. The metric sounds wonderful in theory. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 17 14:21:09 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2313A6925; Mon, 17 Nov 2008 14:21:09 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594C33A6925 for <roll@core3.amsl.com>; Mon, 17 Nov 2008 14:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxOZ+gX8vC4S for <roll@core3.amsl.com>; Mon, 17 Nov 2008 14:21:07 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A2FA23A6907 for <roll@ietf.org>; Mon, 17 Nov 2008 14:21:07 -0800 (PST) Received: from dnab42351f.stanford.edu ([171.66.53.31]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1L2CSx-0007tg-4o; Mon, 17 Nov 2008 14:21:07 -0800 Message-Id: <BF74A839-3B4E-40F7-AA07-56F5CDAFF0F4@cs.stanford.edu> From: Philip Levis <pal@cs.stanford.edu> To: Omprakash Gnawali <gnawali@usc.edu> In-Reply-To: <d4dcddd20811171359p69c344dei57499bc5766251de@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 14:21:04 -0800 References: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> <C542F496.5DD95%jvasseur@cisco.com> <d4dcddd20811141509h248722b6h7feacc5947bc3068@mail.gmail.com> <915E9446-9092-40FA-BFE9-6E9D914DFF40@cs.stanford.edu> <d4dcddd20811171359p69c344dei57499bc5766251de@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 17, 2008, at 1:59 PM, Omprakash Gnawali wrote: >>> > There is a concrete scenario in the draft. Node A sends the data "xyz" > to C. Node B sends the data "xqz" to C. Node C then transmits "xyzq" > to the sink. So scenario is not the problem. The problem is ignoring > the forwarding implications of it as you clearly articulated. I was > surprised that the discussion on this metric was not reflected in the > updated draft. The metric sounds wonderful in theory. > Sure. But what I guess what's confusing about that example is the source address the packet C sends and the destination addresses of the packets A and B send. If the answer to all of these three questions is "C", then it's not occurring in the routing layer. It's a not a routing metric, but rather, a metric for a routing overlay on top of IP. If the answer to any of those questions is not "C," then it's breaking end-to-end. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 17 17:22:55 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624EA3A6A31; Mon, 17 Nov 2008 17:22:55 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AA03A6A31 for <roll@core3.amsl.com>; Mon, 17 Nov 2008 17:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfZkAXF1rleT for <roll@core3.amsl.com>; Mon, 17 Nov 2008 17:22:53 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 8DD9E3A67E1 for <roll@ietf.org>; Mon, 17 Nov 2008 17:22:53 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1439136wag.5 for <roll@ietf.org>; Mon, 17 Nov 2008 17:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Hlq/PSALaPBAKfBJJwhTqp6GT0Ia9sdxASuBlP3A9TM=; b=UGuUQ5cK3pWBjIJ1EhZYIoC+bFePkswIiKHWqb28DyqSzdSI9mi9H92gtl5NWKZ6Wp ZnxtIYi3iKg0fErRXnNQtg39erpIjaBn65EVjisB4commSvBuuHiknAl4iB+ArbXbRB6 ulI+F8/mX8R8aOsUoFHWQU1Da8jxh+Pderqy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=n1ArTvE2lkQvswryuBeMMG2SZXojCsRc+rd24SbWxqTSc3TTX5i6QKbBlSFfKkSKlE lxEZyTtNcA4yZcpSc9sgZLUS6S6w1f7Ph7Qwh3st1T9vilQ4+6JQxYGVfpEOfdbukkq6 edN9KStTKsOj5kM06yootDGnkWgOyJ6OAh73M= Received: by 10.114.39.5 with SMTP id m5mr2853147wam.214.1226971371903; Mon, 17 Nov 2008 17:22:51 -0800 (PST) Received: by 10.115.93.11 with HTTP; Mon, 17 Nov 2008 17:22:51 -0800 (PST) Message-ID: <fa3e97a60811171722w2039088t66209150e07b1d2e@mail.gmail.com> Date: Tue, 18 Nov 2008 10:22:51 +0900 From: "MiJeom Kim" <mijeom@gmail.com> To: "Philip Levis" <pal@cs.stanford.edu> In-Reply-To: <BF74A839-3B4E-40F7-AA07-56F5CDAFF0F4@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <d4dcddd20811130629r755ccd8ej97423d87beb85f7f@mail.gmail.com> <C542F496.5DD95%jvasseur@cisco.com> <d4dcddd20811141509h248722b6h7feacc5947bc3068@mail.gmail.com> <915E9446-9092-40FA-BFE9-6E9D914DFF40@cs.stanford.edu> <d4dcddd20811171359p69c344dei57499bc5766251de@mail.gmail.com> <BF74A839-3B4E-40F7-AA07-56F5CDAFF0F4@cs.stanford.edu> Cc: roll@ietf.org Subject: Re: [Roll] aggregation (Re: ROLL Routing Metrics - WF feed-back needed) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, If I answer the question Phil asked, the destination of A and B's packets is the "sink" not C. So it's breaking end-to-end. I agree that it may not feasible for a node to look at inside of packets and aggregate them especially with data encryption feature. However, I kept the original texts for the metric since not many members gave their opinions on this and we may have more discussion at today's face-to-face meeting. I would definitely reflect consensus (hopefully if we reach) on the next revision. Thanks, Mijeom. On Tue, Nov 18, 2008 at 7:21 AM, Philip Levis <pal@cs.stanford.edu> wrote: > > On Nov 17, 2008, at 1:59 PM, Omprakash Gnawali wrote: > >>>> >> There is a concrete scenario in the draft. Node A sends the data "xyz" >> to C. Node B sends the data "xqz" to C. Node C then transmits "xyzq" >> to the sink. So scenario is not the problem. The problem is ignoring >> the forwarding implications of it as you clearly articulated. I was >> surprised that the discussion on this metric was not reflected in the >> updated draft. The metric sounds wonderful in theory. >> > > Sure. But what I guess what's confusing about that example is the source > address the packet C sends and the destination addresses of the packets A > and B send. If the answer to all of these three questions is "C", then it's > not occurring in the routing layer. It's a not a routing metric, but rather, > a metric for a routing overlay on top of IP. If the answer to any of those > questions is not "C," then it's breaking end-to-end. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Nov 18 14:05:29 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74333A685C; Tue, 18 Nov 2008 14:05:29 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE7328C26A for <roll@core3.amsl.com>; Tue, 18 Nov 2008 14:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALtyvMropKCo for <roll@core3.amsl.com>; Tue, 18 Nov 2008 14:05:28 -0800 (PST) Received: from usstuh502.johnsondiversey.com (mail4.johnsondiversey.com [208.251.229.31]) by core3.amsl.com (Postfix) with ESMTP id C82DA3A677E for <roll@ietf.org>; Tue, 18 Nov 2008 14:05:28 -0800 (PST) From: david.bruemmer@johnsondiversey.com To: roll@ietf.org Message-ID: <OF8BC6EFCC.70649DC5-ON86257505.00792D41-86257505.00792D41@johnsondiversey.com> Date: Tue, 18 Nov 2008 16:03:34 -0600 X-MIMETrack: Serialize by Router on USSTUH502/SVR/CMI(Release 7.0.3FP1|February 24, 2008) at 11/18/2008 16:05:28 MIME-Version: 1.0 Subject: [Roll] David Bruemmer is out of the office. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I will be out of the office starting 11/18/2008 and will not return until 11/21/2008. I will respond to your message when I return. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 19 10:45:03 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE3228C174; Wed, 19 Nov 2008 10:45:03 -0800 (PST) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 823433A6BC4; Wed, 19 Nov 2008 10:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081119184501.823433A6BC4@core3.amsl.com> Date: Wed, 19 Nov 2008 10:45:01 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirements in Low Power and Lossy Networks Author(s) : G. Porcu Filename : draft-ietf-roll-home-routing-reqs-05.txt Pages : 18 Date : 2008-11-19 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-home-routing-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-19103259.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --NextPart-- From roll-bounces@ietf.org Wed Nov 19 16:00:04 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51ADC3A6BDA; Wed, 19 Nov 2008 16:00:04 -0800 (PST) X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2CAC93A6BD3; Wed, 19 Nov 2008 16:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081120000002.2CAC93A6BD3@core3.amsl.com> Date: Wed, 19 Nov 2008 16:00:02 -0800 (PST) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-home-routing-reqs-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Home Automation Routing Requirements in Low Power and Lossy Networks Author(s) : G. Porcu Filename : draft-ietf-roll-home-routing-reqs-06.txt Pages : 17 Date : 2008-11-19 This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-home-routing-reqs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-19155513.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --NextPart-- From roll-bounces@ietf.org Wed Nov 19 19:31:43 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3023A67DB; Wed, 19 Nov 2008 19:31:43 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC033A67DB for <roll@core3.amsl.com>; Wed, 19 Nov 2008 19:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MANGLED_SHOP=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo1DNdsHyyMP for <roll@core3.amsl.com>; Wed, 19 Nov 2008 19:31:41 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 446C53A6405 for <roll@ietf.org>; Wed, 19 Nov 2008 19:31:41 -0800 (PST) Received: from [75.208.91.165] (165.sub-75-208-91.myvzw.com [75.208.91.165]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id mAK3VPcE026466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Nov 2008 19:31:28 -0800 (PST) Message-ID: <4924A57E.4040906@eecs.berkeley.edu> Date: Wed, 19 Nov 2008 15:47:10 -0800 From: Kris Pister <pister@eecs.berkeley.edu> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: mischa.dohler@cttc.es References: <20081111101104.1C4A410C31D@leo> In-Reply-To: <20081111101104.1C4A410C31D@leo> Cc: 'ROLL WG' <roll@ietf.org> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Mischa - we had some discussion of this at the IETF meeting, and it's clear that I'm not doing a good job of explaining my view on the interface to layer 2, and the power/latency tradeoff available there. So let me know which part of this makes sense and which doesn't. There are many L2 protocols that allow me to specify a "listen duty cycle". In several different incarnations of preamble sampling, and in TSMP, this calls for a receiver to wake up periodically to listen to the channel. With todays radios, the cost of this operation is very very roughly (vvr) 1ms worth of radio RX time. So whether this is a scheduled slot in a TDMA network (like TSMP) or an unsynchronized periodic listen, somehow the node must decide how often to wake up and listen. That range can be vvr 10ms to 10s, giving me vvr 10% to 0.01% duty cycle on the receiver, and a corresponding mean link delay of vvr 10ms to 10s (lots and lots of improvements can be made here). In both the synchronized and unsynchronized approaches, the delay is a link property, not a network-wide property. So I might have a 5 hop path with 0.1s total delay, and a 2 hop path with a 10s delay. My routing algorithm needs to be smart enough to: 1) be aware of the existing delay 2) be able to ask L2 if it can afford to decrease it's delay 3) make rational decisions based on the answers to 1 and 2, and then command L2 to make the appropriate change in it's power/latency tradeoff (what I have been calling L3 provisioning of L2 to satisfy L4 QoS). I don't think that this is a layer violation, and I'm not even sure if it's that new of a concept. When JP gets going about MPLS, traffic engineering, and virtual circuits and things like that he says a lot of things that sound familiar to me, but I don't have the networking background to know how close that stuff is to what I'm describing. ksjp Mischa Dohler wrote: > Kris, I actually did not mean to remove latency from the protocol design but > rather proposed to omit it from the list of routing metrics since it can > more or less be inferred from the number of hops or, more precisely, the > number of duty-cycles needed to get the data through - all this, of course, > assuming WSN-tailored duty-cycled MACs and not traditional MACs. I have > however no strong opinion about this since loads of scenarios immediately > pop into my mind where the exact delay matters, such as a combination of > what Phil referred to and your TSMP for industrial monitoring. Mischa. PS: > Tim (Winter), what do you think about that issue in the context of meter > reading? > > > > > -----Original Message----- > From: Kris Pister [mailto:pister@eecs.berkeley.edu] > Sent: Tuesday, November 11, 2008 12:26 AM > To: mischa.dohler@cttc.es > Cc: 'ROLL WG'; Tod Dykstra; amine@sensysnetworks.com > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Mischa - > I agree with everything except the second to last sentence. :) > I haven't read the urban draft recently, but I tried to convince Thomas > to put in the parking monitoring and traffic light applications, since > both of those are actually in production already using LLNs (e.g. > StreetlineNetworks.com, SensysNetworks.com). In both cases, latency is > a real issue. > In any case, even meter and meteorological data has latency > constraints. There are those who believe that the best way to get below > a 0.1% radio duty cycle is to turn all of the radios on for 60 seconds > once a day. There was a product on the market for a while that did this > with a 15 minute cycle. I disagree with that approach, but it's > certainly a LLN MAC that we might see some day, and hopping across > networks like that is going to be painful for most applications. > > ksjp > > Mischa Dohler wrote: > >> Hi Mijeom, all, the conclusion on the instability has - if I understood >> correctly - always been drawn assuming a fairly heavily loaded network. >> > With > >> some exceptions, however, our networks will be lightly loaded and >> duty-cycled, which means that in most cases the processing + queuing + >> transmission delay << L2 delay. Whilst this L2 delay heavily depends on >> > the > >> MAC, it is not a value which fluctuates strongly (if at all) over time. >> > The > >> end-to-end delay, will hence more or less be proportional to the number of >> hops multiplied by the L2 delay. Therefore, although differently >> > motivated, > >> I would agree that delay is not really needed. Having said this, in our >> urban scenario, delay is not really a design issue - Jerry, Kris and >> > Anders > >> may have a different opinion here. Regards, Mischa. >> >> >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> MiJeom Kim >> Sent: Monday, November 10, 2008 7:07 AM >> To: Philip Levis >> Cc: ROLL WG >> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> >> Hi, >> >> We have had quite a few arguments regarding delay related metrics >> through this mailing list. In traditional packet switched networks, >> there are four kinds of delays, which are processing delay, queuing >> delay, transmission delay and propagation delay. There is one more >> delay we make an issue here is L2 delay caused by MAC protocols. The >> document classifies the first three delays as node latency, one of >> node metrics and propagation delay as a link metric. >> >> Let's take into consideration one by one. >> - Processing delay: it's time for a node to process a packet including >> header analysis and error check. I personally prefer to exclude >> processing delay from metrics since it is kind of negligible and is >> depending on node's computing resource which is specified as a node >> metric. >> - Queuing delay: it is depending on time and current node workload >> (the number of packets arrived earlier), thus I prefer to exclude it, >> too. >> - Transmission delay: it's time to push the packet to the link and >> calculated as packet size/bit rate. It's a function of packet size, >> which is hard to make it a metric. We can take bit rate as a factor to >> affect link throughput, though. >> - Propagation delay: as we already agreed, it's close to light speed >> in radio systems and negligible. So I don't think we need this as a >> metric. >> - L2 delay: as I mentioned before, it's very fluctuating by time and >> depending on MAC protocols. Due to the all dependency I don't think >> it's a good idea to take L2 delay as a metric. >> >> To summary, delay related attributes are mostly varying as time and >> depending on variables such as packet size and workload. Therefore, I >> don't think anything above can be a feasible routing metric. >> Otherwise, we need really well designed schemes to take care of all >> the variables affecting the delays and to avoid instability, which is >> pretty skeptical. >> >> Always welcome other opinions, >> >> Thanks, >> Mijeom. >> >> On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis <pal@cs.stanford.edu> wrote: >> >> >>> On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: >>> >>> >>> >>>> Hi Mijeom, >>>> >>>> I suspect that in many radio systems with operations similar to IEEE >>>> > 802, > >>>> the propagation delay you are talking about is almost useless taken >>>> separately since the transaction is only complete when an ack is >>>> > received > >>>> back that enables a wireless router to free the resources allocated to >>>> >>>> >> the >> >> >>>> frame and go back to sleep. The time between acking a received frame and >>>> receiving the ack for that frame being forwarded is the real latency of >>>> > a > >>>> node. If we want to sustain a given rate R with a Latency L, we need R*L >>>> >>>> >> in >> >> >>>> buffer space. Considering that memory is often a constrained resource >>>> >>>> >> this >> >> >>>> is something that we need to account for. >>>> >>>> >>> Pascal, >>> >>> I'm not sure this is really an issue. You're talking about layer 2 acks? >>> Generally those are always transmitted within a quite deterministic and >>> >>> >> tiny >> >> >>> time interval; furthermore, media access is designed to prevent >>> >>> >> transmitting >> >> >>> on top of them (e.g., through 15.4's double channel sense, or 802.11's >>> >>> >> NAV). >> >> >>> The idea that a node has to hold onto a packet for a long time waiting >>> > for > >>> >>> >> a >> >> >>> layer 2 ack just isn't a problem, as they are generally synchronous >>> > rather > >>> than asynchronous (do not go through media access). >>> >>> Phil >>> >>> >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 20 05:39:08 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308AC3A6AD1; Thu, 20 Nov 2008 05:39:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD333A6AD1 for <roll@core3.amsl.com>; Thu, 20 Nov 2008 05:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGigOSqVBbIx for <roll@core3.amsl.com>; Thu, 20 Nov 2008 05:39:06 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D557E3A6837 for <roll@ietf.org>; Thu, 20 Nov 2008 05:39:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="107215778" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Nov 2008 13:39:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAKDd5B6010252 for <roll@ietf.org>; Thu, 20 Nov 2008 05:39:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKDd5JC005002 for <roll@ietf.org>; Thu, 20 Nov 2008 13:39:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 05:39:05 -0800 Received: from [130.129.76.145] ([10.21.69.241]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 05:39:05 -0800 Message-Id: <09267F3A-1023-4506-8860-24E1D3B1409F@cisco.com> From: JP Vasseur <jvasseur@cisco.com> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 20 Nov 2008 07:39:04 -0600 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 20 Nov 2008 13:39:05.0435 (UTC) FILETIME=[5B4402B0:01C94B15] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=207; t=1227188345; x=1228052345; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20ROLL=20WG=20Meeting=20Minutes=20posted |Sender:=20; bh=WByWxGgU9RvlSqZ+gTJDzXzqstKfIPQ7jEvi5X+DBwA=; b=P83L/w9VYTdXYG6Ys39SDtnlGXpJXhbN5S5iL14b8RJJmabJn2xUzupGMN 5i37kmt0vSMFbZv1MC4G4GZ3uskvCDBZyJFxVsVgnVHTKJq+VvYYQ5exAd2D fl6I4g+f2l; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] ROLL WG Meeting Minutes posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, The minutes of the ROLL WG meeting - IETF-73 have been posted: http://www.ietf.org/proceedings/08nov/minutes/roll.txt Please provide your comments if any by November 28. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 20 07:51:18 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806743A683B; Thu, 20 Nov 2008 07:51:18 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224323A683B for <roll@core3.amsl.com>; Thu, 20 Nov 2008 07:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SHOP=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmgFVGGc-amF for <roll@core3.amsl.com>; Thu, 20 Nov 2008 07:51:15 -0800 (PST) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id C0FA23A67B5 for <roll@ietf.org>; Thu, 20 Nov 2008 07:51:14 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id mAKFn193005764; Thu, 20 Nov 2008 16:49:01 +0100 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) by castor (Postfix) with ESMTP id 6919C2FC286; Thu, 20 Nov 2008 16:49:01 +0100 (CET) From: "Mischa Dohler" <mischa.dohler@cttc.es> To: "'Kris Pister'" <pister@eecs.berkeley.edu> Date: Thu, 20 Nov 2008 16:44:56 +0100 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AclKwhQ2HhL0EuBbT+et8J8e8OaO0wAX34rA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <4924A57E.4040906@eecs.berkeley.edu> Message-Id: <20081120154901.6919C2FC286@castor> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Thu, 20 Nov 2008 16:49:01 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: 'ROLL WG' <roll@ietf.org> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Kris, I am not quite sure why you address this email to me as I fully see your point and, as per below email exchanges, pretty much agree with you. My last emails were just to highlight that you can do many hops in a single MAC cycle and - if you use the same MACs under the same conditions - you can calculate the e2e simply and vvr by having the numbers of hops. However, if you start relying on MACs where you can change the cycle in each radio in dependency of some metrics (and I don't think that traffic congestions will have a major impact here), then this simple heuristics of course breaks down. Including link delay into the specs may hence reflect better your needs. A general remark to the group, I am not sure why we are generally spending so much time discussing this in such great details? I understand that some good design specs help the protocol development but if we cannot agree why not simply cater for the most demanding parameter(s) and then hope to be able to relax this? Engineering work is iterative in nature, so let's talk again when we will have some protocols on the table. Mischa. PS: I think what will give us more headache on the long run, however, is what Phil alluded at, i.e. the problem with aggregation and e2e breakdown. Did you discuss this at the meeting? -----Original Message----- From: Kris Pister [mailto:pister@eecs.berkeley.edu] Sent: Thursday, November 20, 2008 12:47 AM To: mischa.dohler@cttc.es Cc: 'ROLL WG' Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed Mischa - we had some discussion of this at the IETF meeting, and it's clear that I'm not doing a good job of explaining my view on the interface to layer 2, and the power/latency tradeoff available there. So let me know which part of this makes sense and which doesn't. There are many L2 protocols that allow me to specify a "listen duty cycle". In several different incarnations of preamble sampling, and in TSMP, this calls for a receiver to wake up periodically to listen to the channel. With todays radios, the cost of this operation is very very roughly (vvr) 1ms worth of radio RX time. So whether this is a scheduled slot in a TDMA network (like TSMP) or an unsynchronized periodic listen, somehow the node must decide how often to wake up and listen. That range can be vvr 10ms to 10s, giving me vvr 10% to 0.01% duty cycle on the receiver, and a corresponding mean link delay of vvr 10ms to 10s (lots and lots of improvements can be made here). In both the synchronized and unsynchronized approaches, the delay is a link property, not a network-wide property. So I might have a 5 hop path with 0.1s total delay, and a 2 hop path with a 10s delay. My routing algorithm needs to be smart enough to: 1) be aware of the existing delay 2) be able to ask L2 if it can afford to decrease it's delay 3) make rational decisions based on the answers to 1 and 2, and then command L2 to make the appropriate change in it's power/latency tradeoff (what I have been calling L3 provisioning of L2 to satisfy L4 QoS). I don't think that this is a layer violation, and I'm not even sure if it's that new of a concept. When JP gets going about MPLS, traffic engineering, and virtual circuits and things like that he says a lot of things that sound familiar to me, but I don't have the networking background to know how close that stuff is to what I'm describing. ksjp Mischa Dohler wrote: > Kris, I actually did not mean to remove latency from the protocol design but > rather proposed to omit it from the list of routing metrics since it can > more or less be inferred from the number of hops or, more precisely, the > number of duty-cycles needed to get the data through - all this, of course, > assuming WSN-tailored duty-cycled MACs and not traditional MACs. I have > however no strong opinion about this since loads of scenarios immediately > pop into my mind where the exact delay matters, such as a combination of > what Phil referred to and your TSMP for industrial monitoring. Mischa. PS: > Tim (Winter), what do you think about that issue in the context of meter > reading? > > > > > -----Original Message----- > From: Kris Pister [mailto:pister@eecs.berkeley.edu] > Sent: Tuesday, November 11, 2008 12:26 AM > To: mischa.dohler@cttc.es > Cc: 'ROLL WG'; Tod Dykstra; amine@sensysnetworks.com > Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > Mischa - > I agree with everything except the second to last sentence. :) > I haven't read the urban draft recently, but I tried to convince Thomas > to put in the parking monitoring and traffic light applications, since > both of those are actually in production already using LLNs (e.g. > StreetlineNetworks.com, SensysNetworks.com). In both cases, latency is > a real issue. > In any case, even meter and meteorological data has latency > constraints. There are those who believe that the best way to get below > a 0.1% radio duty cycle is to turn all of the radios on for 60 seconds > once a day. There was a product on the market for a while that did this > with a 15 minute cycle. I disagree with that approach, but it's > certainly a LLN MAC that we might see some day, and hopping across > networks like that is going to be painful for most applications. > > ksjp > > Mischa Dohler wrote: > >> Hi Mijeom, all, the conclusion on the instability has - if I understood >> correctly - always been drawn assuming a fairly heavily loaded network. >> > With > >> some exceptions, however, our networks will be lightly loaded and >> duty-cycled, which means that in most cases the processing + queuing + >> transmission delay << L2 delay. Whilst this L2 delay heavily depends on >> > the > >> MAC, it is not a value which fluctuates strongly (if at all) over time. >> > The > >> end-to-end delay, will hence more or less be proportional to the number of >> hops multiplied by the L2 delay. Therefore, although differently >> > motivated, > >> I would agree that delay is not really needed. Having said this, in our >> urban scenario, delay is not really a design issue - Jerry, Kris and >> > Anders > >> may have a different opinion here. Regards, Mischa. >> >> >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> MiJeom Kim >> Sent: Monday, November 10, 2008 7:07 AM >> To: Philip Levis >> Cc: ROLL WG >> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >> >> Hi, >> >> We have had quite a few arguments regarding delay related metrics >> through this mailing list. In traditional packet switched networks, >> there are four kinds of delays, which are processing delay, queuing >> delay, transmission delay and propagation delay. There is one more >> delay we make an issue here is L2 delay caused by MAC protocols. The >> document classifies the first three delays as node latency, one of >> node metrics and propagation delay as a link metric. >> >> Let's take into consideration one by one. >> - Processing delay: it's time for a node to process a packet including >> header analysis and error check. I personally prefer to exclude >> processing delay from metrics since it is kind of negligible and is >> depending on node's computing resource which is specified as a node >> metric. >> - Queuing delay: it is depending on time and current node workload >> (the number of packets arrived earlier), thus I prefer to exclude it, >> too. >> - Transmission delay: it's time to push the packet to the link and >> calculated as packet size/bit rate. It's a function of packet size, >> which is hard to make it a metric. We can take bit rate as a factor to >> affect link throughput, though. >> - Propagation delay: as we already agreed, it's close to light speed >> in radio systems and negligible. So I don't think we need this as a >> metric. >> - L2 delay: as I mentioned before, it's very fluctuating by time and >> depending on MAC protocols. Due to the all dependency I don't think >> it's a good idea to take L2 delay as a metric. >> >> To summary, delay related attributes are mostly varying as time and >> depending on variables such as packet size and workload. Therefore, I >> don't think anything above can be a feasible routing metric. >> Otherwise, we need really well designed schemes to take care of all >> the variables affecting the delays and to avoid instability, which is >> pretty skeptical. >> >> Always welcome other opinions, >> >> Thanks, >> Mijeom. >> >> On Sat, Nov 8, 2008 at 5:57 AM, Philip Levis <pal@cs.stanford.edu> wrote: >> >> >>> On Nov 7, 2008, at 8:32 AM, Pascal Thubert (pthubert) wrote: >>> >>> >>> >>>> Hi Mijeom, >>>> >>>> I suspect that in many radio systems with operations similar to IEEE >>>> > 802, > >>>> the propagation delay you are talking about is almost useless taken >>>> separately since the transaction is only complete when an ack is >>>> > received > >>>> back that enables a wireless router to free the resources allocated to >>>> >>>> >> the >> >> >>>> frame and go back to sleep. The time between acking a received frame and >>>> receiving the ack for that frame being forwarded is the real latency of >>>> > a > >>>> node. If we want to sustain a given rate R with a Latency L, we need R*L >>>> >>>> >> in >> >> >>>> buffer space. Considering that memory is often a constrained resource >>>> >>>> >> this >> >> >>>> is something that we need to account for. >>>> >>>> >>> Pascal, >>> >>> I'm not sure this is really an issue. You're talking about layer 2 acks? >>> Generally those are always transmitted within a quite deterministic and >>> >>> >> tiny >> >> >>> time interval; furthermore, media access is designed to prevent >>> >>> >> transmitting >> >> >>> on top of them (e.g., through 15.4's double channel sense, or 802.11's >>> >>> >> NAV). >> >> >>> The idea that a node has to hold onto a packet for a long time waiting >>> > for > >>> >>> >> a >> >> >>> layer 2 ack just isn't a problem, as they are generally synchronous >>> > rather > >>> than asynchronous (do not go through media access). >>> >>> Phil >>> >>> >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 20 08:29:37 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4DD3A68BE; Thu, 20 Nov 2008 08:29:37 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A2C3A6806 for <roll@core3.amsl.com>; Thu, 20 Nov 2008 08:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDyal5vNH5MF for <roll@core3.amsl.com>; Thu, 20 Nov 2008 08:29:35 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 5B9893A69D7 for <roll@ietf.org>; Thu, 20 Nov 2008 08:29:35 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 17:29:31 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 17:29:32 +0100 Message-ID: <D4EF10CCEB2CE742BEEA9838C590B0E809C5BA73@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unique destinations and the protocol survey draft Thread-index: AclLLSsbBZ0Rq0E3QUi0sk2KMKvbkQ== From: <giyyarpuram.madhusudan@orange-ftgroup.com> To: <roll@ietf.org> X-OriginalArrivalTime: 20 Nov 2008 16:29:31.0968 (UTC) FILETIME=[2AC11C00:01C94B2D] Subject: [Roll] Unique destinations and the protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org The protocols survey document states "However, as many low-power and lossy networks behave principally as data collection networks and principally communicate through routers to data collection points in the larger Internet, scaling with the number of such collection points is reasonable. Protocols whose state scales with the number of destinations pass." I can give several counter examples. Home automation very often involves control - switching lights on and off, opening and closing shutters. I can make the same case for Building automation: lights, heating are turned on and off or turned on and down. Don't know much about Industrial automation. The claim is probably most valid for Urban networks except for one very important case, AMI. Smart energy solutions involve demand response and load control. This implies messages from the utility to the electric meter. So here again we have a large number of unique destinations. It is entirely possible that the data traffic for commands is much smaller than reporting traffic. However the number of unique destinations is not orders of magnitude less than N and will very likely be greater than L. Madhu _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 20 10:21:28 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0725E3A6A10; Thu, 20 Nov 2008 10:21:28 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6FD3A6A10 for <roll@core3.amsl.com>; Thu, 20 Nov 2008 10:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cle7ktnJWm0a for <roll@core3.amsl.com>; Thu, 20 Nov 2008 10:21:26 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id F00633A69DC for <roll@ietf.org>; Thu, 20 Nov 2008 10:21:25 -0800 (PST) Received: from dnab42205c.stanford.edu ([171.66.32.92]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1L3E9c-0006V3-6A; Thu, 20 Nov 2008 10:21:24 -0800 Message-Id: <92893C8F-E0CA-42FA-A63D-0AD331A2BF83@cs.stanford.edu> From: Philip Levis <pal@cs.stanford.edu> To: <giyyarpuram.madhusudan@orange-ftgroup.com> <giyyarpuram.madhusudan@orange-ftgroup.com> In-Reply-To: <D4EF10CCEB2CE742BEEA9838C590B0E809C5BA73@ftrdmel2> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 10:21:23 -0800 References: <D4EF10CCEB2CE742BEEA9838C590B0E809C5BA73@ftrdmel2> X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: roll@ietf.org Subject: Re: [Roll] Unique destinations and the protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 20, 2008, at 8:29 AM, <giyyarpuram.madhusudan@orange- ftgroup.com> <giyyarpuram.madhusudan@orange-ftgroup.com> wrote: > > The protocols survey document states > > "However, as many low-power and lossy networks behave principally as > data collection networks and principally communicate through routers > to > data collection points in the larger Internet, scaling with the number > of such collection points is reasonable. Protocols whose state scales > with the number of destinations pass." > > I can give several counter examples. > > Home automation very often involves control - switching lights on and > off, opening and closing shutters. > I can make the same case for Building automation: lights, heating are > turned on and off or turned on and down. > > Don't know much about Industrial automation. > The claim is probably most valid for Urban networks except for one > very > important case, AMI. > Smart energy solutions involve demand response and load control. This > implies messages from the utility to the electric meter. So here again > we have a large number of unique destinations. > > > It is entirely possible that the data traffic for commands is much > smaller than reporting traffic. However the number of unique > destinations is not orders of magnitude less than N and will very > likely > be greater than L. > > Madhu Madhu, I fear you might be misinterpreting that paragraph. The point is not to say that all apps have a small D, but rather that apps which do have a small D should not have to pay a big price to maintain many unused routes. Apps that need many routes of course need to maintain them. That's why it says "many" and not "all." The "many" is big enough that we can't just ignore it. Does that make sense? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Nov 20 22:33:26 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF633A685D; Thu, 20 Nov 2008 22:33:26 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0310F3A685D for <roll@core3.amsl.com>; Thu, 20 Nov 2008 22:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeRqYBoA7VAh for <roll@core3.amsl.com>; Thu, 20 Nov 2008 22:33:22 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 650453A6828 for <roll@ietf.org>; Thu, 20 Nov 2008 22:33:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208,217";a="26332613" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2008 06:33:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAL6XKcb029312 for <roll@ietf.org>; Fri, 21 Nov 2008 07:33:20 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAL6XKIT001018 for <roll@ietf.org>; Fri, 21 Nov 2008 06:33:20 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 07:33:19 +0100 Received: from [10.0.4.22] ([10.61.105.11]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 07:33:12 +0100 Message-Id: <F2835261-2622-4C1F-AEAE-1CDC151ABDA9@cisco.com> From: JP Vasseur <jvasseur@cisco.com> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 21 Nov 2008 07:33:04 +0100 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 21 Nov 2008 06:33:13.0514 (UTC) FILETIME=[078C08A0:01C94BA3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3425; t=1227249200; x=1228113200; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20New=20ROLL=20WG=20Milestone=20=22Done=22 |Sender:=20; bh=1GwzQUhbV/RGLsuMGzxCh9T74OY0eAOVaT052ENYVsM=; b=SEc//pbQZNnehIZShLTgq2cbA9NgTDviIKxuBHaAm9weCNwLXF9AT3SxCg RUDu14dd9PFn0JS3Lp8ZyGQxrEW05SGL8/MDL8sUW2OWYOwwIVZBnnBPr+lv UY3rsv3fIU; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] New ROLL WG Milestone "Done" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: multipart/mixed; boundary="===============1857223770==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1857223770== Content-Type: multipart/alternative; boundary=Apple-Mail-33--166118212 --Apple-Mail-33--166118212 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Jul 2008 Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Jul 2008 Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. Nov 2008 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. Apr 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. Jun 2009 Recharter or close. --Apple-Mail-33--166118212 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" = style=3D"font-family: Times; font-size: 16px; "><table style=3D"position: = static; z-index: auto; "><tbody><tr align=3D"left" valign=3D"top"><td = width=3D"70" valign=3D"top">Jul 2008</td><td>  </td><td>Submit = Routing requirements for Industrial applications to the IESG to be = considered as an Informational RFC.</td></tr><tr align=3D"left" = valign=3D"top"><td width=3D"70" = valign=3D"top"><b>Done</b></td><td><b>  </b></td><td><b>Submit = Routing requirements for Connected Home networks applications to the = IESG to be considered as an Informational RFC.</b></td></tr><tr = align=3D"left" valign=3D"top"><td width=3D"70" valign=3D"top">Jul = 2008</td><td>  </td><td>Submit Routing requirements for = Building applications to the IESG to be considered as an Informational = RFC.</td></tr><tr align=3D"left" valign=3D"top"><td width=3D"70" = valign=3D"top">Done</td><td>  </td><td>Submit Routing = requirements for Urban networks applications to the IESG to be = considered as an Informational RFC.</td></tr><tr align=3D"left" = valign=3D"top"><td width=3D"70" valign=3D"top">Nov = 2008</td><td>  </td><td>Submit Routing metrics for LLNs = document to the IESG to be considered as a Proposed = Standard.</td></tr><tr align=3D"left" valign=3D"top"><td width=3D"70" = valign=3D"top">Feb 2009</td><td>  </td><td>Submit Protocol = Survey to the IESG to be considered as an Informational = RFC.</td></tr><tr align=3D"left" valign=3D"top"><td width=3D"70" = valign=3D"top">Apr 2009</td><td>  </td><td>Submit Security = Framework to the IESG to be considered as an Informational = RFC</td></tr><tr align=3D"left" valign=3D"top"><td width=3D"70" = valign=3D"top">May 2009</td><td>  </td><td>Submit the Routing = for LLNs Architecture document to the IESG as an Informational = RFC.</td></tr><tr align=3D"left" valign=3D"top"><td width=3D"70" = valign=3D"top">Jun 2009</td><td>  </td><td>Recharter or = close.</td></tr></tbody></table></span></body></html>= --Apple-Mail-33--166118212-- --===============1857223770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1857223770==-- From roll-bounces@ietf.org Thu Nov 20 22:36:48 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094B13A6A99; Thu, 20 Nov 2008 22:36:48 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82BB33A6A93 for <roll@core3.amsl.com>; Thu, 20 Nov 2008 22:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69rPAqYWUBX6 for <roll@core3.amsl.com>; Thu, 20 Nov 2008 22:36:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4B0CD3A685D for <roll@ietf.org>; Thu, 20 Nov 2008 22:36:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208,217";a="26332732" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2008 06:36:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAL6ahdl028560 for <roll@ietf.org>; Fri, 21 Nov 2008 07:36:43 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAL6ahWQ001401 for <roll@ietf.org>; Fri, 21 Nov 2008 06:36:43 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 07:36:42 +0100 Received: from [10.0.4.22] ([10.61.105.11]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 07:36:42 +0100 Message-Id: <7C1A2E64-C1B0-472E-B354-77F290BBC80D@cisco.com> From: JP Vasseur <jvasseur@cisco.com> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 21 Nov 2008 07:36:40 +0100 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 21 Nov 2008 06:36:42.0398 (UTC) FILETIME=[840D33E0:01C94BA3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2757; t=1227249403; x=1228113403; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Working=20Group=20Last=20Call=3A=20draft-ietf-r oll-protocols-survey-02 |Sender:=20; bh=HYo3brqIrElAcdCLeO/W7aXGZNCuZvs/bc+izT9x3MM=; b=nCU5vHNFEsW3VvbxwviHvoSvsGGxjXOCx4DzZ6K1fdjs3gWbLNzMhH7GtM dqfh2rVHIOJPXnYb4kiWmdLq85+klFEOpKbaWPmRg6/ZAX+N1P9YZ4pH/rQi CmM3PK2lBL; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] Working Group Last Call: draft-ietf-roll-protocols-survey-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: multipart/mixed; boundary="===============1055871718==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1055871718== Content-Type: multipart/alternative; boundary=Apple-Mail-34--165902627 --Apple-Mail-34--165902627 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, draft-ietf-roll-protocols-survey-02 is now fully stable, the last revision has been published after the ROLL Interim meeting in October and all comments received so far had been addressed. This emails start a 2-week Working Group Last Call that will end on December 5 at noon ET. Please send your comments to the authors and on the mailing list. Thanks. JP. --Apple-Mail-34--165902627 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; "><font class=3D"Apple-style-span" face=3D"Arial">Dear = WG,</font><div><font class=3D"Apple-style-span" = face=3D"Arial"><br></font></div><div><span class=3D"Apple-style-span" = style=3D"white-space: pre-wrap; "><font class=3D"Apple-style-span" = face=3D"Arial">draft-ietf-roll-protocols-survey-02 is now fully stable, = the last revision has been published after the ROLL Interim meeting in = October and all comments received so far had been = addressed. </font></span></div><div><span class=3D"Apple-style-span" = style=3D"white-space: pre-wrap;"><font class=3D"Apple-style-span" = face=3D"Arial"><br></font></span></div><div><span = class=3D"Apple-style-span" style=3D"white-space: pre-wrap; "><font = class=3D"Apple-style-span" face=3D"Arial">This emails start a 2-week = Working Group Last Call that will end on December 5 at noon = ET.</font></span></div><div><span class=3D"Apple-style-span" = style=3D"white-space: pre-wrap; "><font class=3D"Apple-style-span" = face=3D"Arial"><br></font></span></div><div><span = class=3D"Apple-style-span" style=3D"white-space: pre-wrap; "><font = class=3D"Apple-style-span" face=3D"Arial">Please send your comments to = the authors and on the mailing list.</font></span></div><div><span = class=3D"Apple-style-span" style=3D"white-space: pre-wrap; "><font = class=3D"Apple-style-span" = face=3D"Arial"><br></font></span></div><div><span = class=3D"Apple-style-span" style=3D"white-space: pre-wrap; "><font = class=3D"Apple-style-span" = face=3D"Arial">Thanks.</font></span></div><div><span = class=3D"Apple-style-span" style=3D"white-space: pre-wrap; "><font = class=3D"Apple-style-span" = face=3D"Arial"><br></font></span></div><div><span = class=3D"Apple-style-span" style=3D"white-space: pre-wrap; "><font = class=3D"Apple-style-span" = face=3D"Arial">JP.</font></span></div></div></body></html>= --Apple-Mail-34--165902627-- --===============1055871718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1055871718==-- From roll-bounces@ietf.org Fri Nov 21 02:58:08 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04FC3A68AB; Fri, 21 Nov 2008 02:58:08 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E09D3A68AB for <roll@core3.amsl.com>; Fri, 21 Nov 2008 02:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcJNJ+lHYw2a for <roll@core3.amsl.com>; Fri, 21 Nov 2008 02:58:06 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 0DE6E3A67B4 for <roll@ietf.org>; Fri, 21 Nov 2008 02:58:05 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 11:57:59 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:58:02 +0100 Message-ID: <D4EF10CCEB2CE742BEEA9838C590B0E809C5BCF2@ftrdmel2> In-Reply-To: <92893C8F-E0CA-42FA-A63D-0AD331A2BF83@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Unique destinations and the protocol survey draft Thread-index: AclLPM04hl00Ycd9QD2bIELqAdaiAwAg7tfw References: <D4EF10CCEB2CE742BEEA9838C590B0E809C5BA73@ftrdmel2> <92893C8F-E0CA-42FA-A63D-0AD331A2BF83@cs.stanford.edu> From: <giyyarpuram.madhusudan@orange-ftgroup.com> To: <pal@cs.stanford.edu> X-OriginalArrivalTime: 21 Nov 2008 10:57:59.0448 (UTC) FILETIME=[044D3180:01C94BC8] Cc: roll@ietf.org Subject: Re: [Roll] Unique destinations and the protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org >> >> The protocols survey document states >>However, as many low-power and lossy networks behave principally as >> data collection networks and principally communicate through routers >> to data collection points in the larger Internet, scaling with the >> number of such collection points is reasonable. Protocols whose state >> scales with the number of destinations pass." >> I can give several counter examples. >> Home automation very often involves control - switching lights on and >> off, opening and closing shutters. >> I can make the same case for Building automation: lights, heating are >> turned on and off or turned on and down. >> >> Don't know much about Industrial automation. >> The claim is probably most valid for Urban networks except for one >> very important case, AMI. >> Smart energy solutions involve demand response and load control. This >> implies messages from the utility to the electric meter. So here again >> we have a large number of unique destinations. >>It is entirely possible that the data traffic for commands is much >> smaller than reporting traffic. However the number of unique >> destinations is not orders of magnitude less than N and will very >> likely be greater than L. >> Madhu > Madhu, > I fear you might be misinterpreting that paragraph. > The point is not to say that all apps have a small D, but rather that apps > which do have a small D should not have to pay a big price to maintain many > unused routes. Apps that need many routes of course need to maintain them. > That's why it says "many" and not "all." The "many" is big enough that we can't just ignore it. > Does that make sense? > Phil Phil, I agree that apps with small D should not have to pay the price for big D apps. However there seems to be the supposition that the small D is the "general" case and the big D is the exception. Hence claims like O(D) scaling passes or O(D) route updates passes. It seems to me that the trend in "many" apps is towards more active contol as opposed to pure data collection. This has been true in AMR which is becoming more AMI. Also this is not a just a sensor/actuator ratio. Even for sensors that only send reports one may want to send configuration commands that change the frequency of reporting or request frequent updates for a short period of time or change the threshold for events. However I would buy the argument that data collection traffic will be much higher than command/query/configure traffic. So perhaps it is a question of optimizing for data collection and shifting the burden for command traffic onto the originator (such as source routing). Madhu _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Nov 21 10:54:47 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0033A682E; Fri, 21 Nov 2008 10:54:47 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218533A682E for <roll@core3.amsl.com>; Fri, 21 Nov 2008 10:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwdmZ+u06gW4 for <roll@core3.amsl.com>; Fri, 21 Nov 2008 10:54:45 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 49B9E3A6452 for <roll@ietf.org>; Fri, 21 Nov 2008 10:54:45 -0800 (PST) Received: from cs-33-111.cs.ucla.edu ([131.179.33.111]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1L3b9P-0005Dm-PN; Fri, 21 Nov 2008 10:54:44 -0800 Message-Id: <E8E54775-5FD7-429A-8D71-4581E265E62A@cs.stanford.edu> From: Philip Levis <pal@cs.stanford.edu> To: <giyyarpuram.madhusudan@orange-ftgroup.com> <giyyarpuram.madhusudan@orange-ftgroup.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 21 Nov 2008 10:54:44 -0800 X-Mailer: Apple Mail (2.929.2) X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06 Cc: ROLL WG <roll@ietf.org> Subject: Re: [Roll] Unique destinations and the protocol survey draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Nov 21, 2008, at 2:58 AM, <giyyarpuram.madhusudan@orange- ftgroup.com> <giyyarpuram.madhusudan@orange-ftgroup.com> wrote: >> hat make sense? >> Phil > Phil, > I agree that apps with small D should not have to pay the price for > big > D apps.=20 > However there seems to be the supposition that the small D is the > "general" case and the big D > is the exception. What text in the document leads you to that conclusion? I try to pick words very carefully. "Many" implies neither a majority nor a plurality[1]; trying to make broad claims over which apps will be more common than others would be a bit silly at this point. The point of that claim is that the "many" is large enough that putting our head in the sand and just assuming O(N) state is always OK is, well, *not* OK. > Hence claims like O(D) scaling passes or O(D) route > updates passes. > It seems to me that the trend in "many" apps is towards more active > contol as opposed to pure data > collection. This has been true in AMR which is becoming more AMI.=20 > Also this is not a just a sensor/actuator ratio. Even for sensors that > only send reports one may want > to send configuration commands that change the frequency of > reporting or > request frequent updates for a > short period of time or change the threshold for events. True. But the whole point of O(D) is that it subsumes this; if you need unicast communication to every node in the network; then D=N and so you can have O(N). > > However I would buy the argument that data collection traffic will be > much higher than=20 > command/query/configure traffic. So perhaps it is a question of > optimizing for data collection=20 > and shifting the burden for command traffic onto the originator > (such as > source routing). Well, there are a lot of reasons why source routing raises issues, in particular adaptation to the dynamicity typical to low-power wireless links. Phil [1] "John McCain received many votes this year;" "Many Americans believe it's time for change;" "Many households use NATs;" "Many websites do not work properly with IPv6." _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Nov 24 02:19:03 2008 Return-Path: <roll-bounces@ietf.org> X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DD53A681D; Mon, 24 Nov 2008 02:19:03 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE81F3A681D for <roll@core3.amsl.com>; Mon, 24 Nov 2008 02:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jp2ErkBJUvF for <roll@core3.amsl.com>; Mon, 24 Nov 2008 02:19:02 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id DFABA3A67B3 for <roll@ietf.org>; Mon, 24 Nov 2008 02:19:01 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 11:18:56 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 11:18:54 +0100 Message-ID: <D4EF10CCEB2CE742BEEA9838C590B0E809C8B7D5@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Upstream and downstream flows (was Unique destinations and the protocol survey draft) Thread-index: AclOHg2tQNTAqMl3TiGKLAinVugOMg== From: <giyyarpuram.madhusudan@orange-ftgroup.com> To: <roll@ietf.org> X-OriginalArrivalTime: 24 Nov 2008 10:18:56.0137 (UTC) FILETIME=[0ED18F90:01C94E1E] Subject: [Roll] Upstream and downstream flows (was Unique destinations and the protocol survey draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks <roll.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/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> Content-Type: multipart/mixed; boundary="===============1159977738==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1159977738== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94E1E.0DFB1204" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94E1E.0DFB1204 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have had a couple of offlist exchanges with Phil on this issue. Here is a reformulation of my concern. Many LLNs are I think characterised by an asymmetry in the upstream and downstream flows. The upstream flows of many LLN applications are characterised by small D. However even for these applications the downstream flows do not necessarily share this property. Thus a criterion that applies to upstream does not necessarily apply to downstream. Madhu ------_=_NextPart_001_01C94E1E.0DFB1204 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7651.59"> <TITLE>Upstream and downstream flows (was Unique destinations and the = protocol survey draft)

I have had a couple of offlist = exchanges with Phil on this issue.

Here is a reformulation of my = concern.

Many LLNs are I think = characterised by an asymmetry in the upstream and downstream = flows.
The upstream flows of many LLN = applications are characterised by small D.
However even for these = applications the downstream flows do not necessarily share this = property.

Thus a criterion that applies to = upstream does not necessarily apply to downstream.

Madhu


------_=_NextPart_001_01C94E1E.0DFB1204-- --===============1159977738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1159977738==-- From roll-bounces@ietf.org Mon Nov 24 03:39:55 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882513A6951; Mon, 24 Nov 2008 03:39:55 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BE93A6951 for ; Mon, 24 Nov 2008 03:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blSbkKL9GBBN for ; Mon, 24 Nov 2008 03:39:53 -0800 (PST) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.248]) by core3.amsl.com (Postfix) with ESMTP id BC5D13A6929 for ; Mon, 24 Nov 2008 03:39:53 -0800 (PST) Received: by hs-out-0708.google.com with SMTP id 4so828675hsl.5 for ; Mon, 24 Nov 2008 03:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ioqbxMjI0guiw/8WmNEoJwWtY1LEKOzf2eR52FS583Y=; b=NwVY+DdwlYbgVg/0q+XpiW/HZN2HVr062pgJ7MNv/xSzTXBIYWwqpeZGa5b9BEvZin JgXSu02kfZ55bIHFTwLC4LF8kFzeECaHvn6jxTetD6MtL3m7CzUltuaQjox9BV2bEMuf 1XvjAU10VkVG90FC7BPdx/3wTjsqKlblA0JmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=H5OzxMLhRCX3em7eD+7rj/IJFwyIT1q2tldcgpdNN3ROx+MqpTsNAwqNA1n0LfjMQY i0ER394jASMbrDMJdZGhZ055BLf5Sby4qUWhVga0ho0IdefPgP8+hDBRrz2wco9M1mC+ 9z0MaKOxoa58jRxSPhnzII0pyNaQYxtB9Hc6I= Received: by 10.90.94.12 with SMTP id r12mr1990395agb.119.1227526791603; Mon, 24 Nov 2008 03:39:51 -0800 (PST) Received: by 10.90.102.19 with HTTP; Mon, 24 Nov 2008 03:39:51 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 03:39:51 -0800 From: "Omprakash Gnawali" To: giyyarpuram.madhusudan@orange-ftgroup.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: 54c9243e5606c1aa Cc: roll@ietf.org Subject: Re: [Roll] Upstream and downstream flows (was Unique destinations and the protocol survey draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Mon, Nov 24, 2008 at 2:18 AM, wrote: > > I have had a couple of offlist exchanges with Phil on this issue. > > Here is a reformulation of my concern. > > Many LLNs are I think characterised by an asymmetry in the upstream and > downstream flows. > The upstream flows of many LLN applications are characterised by small D. > However even for these applications the downstream flows do not necessarily > share this property. > > Thus a criterion that applies to upstream does not necessarily apply to > downstream. > In one of the research networks we have built and deployed for structural health monitoring using accelerometers, we used network-wide dissemination to command and control the sensors. The instances when we had to command/control a single sensor were so few and rare that we used network-wide dissemination and filter the messages at higher layers to simulate a single destination for the command and control. If D starts to become too large, perhaps the system can switch to network-wide messaging to prevent D from becoming too large and avoid having to store too much state. So, yes the network could have a large number of unique destinations but that does not necessarily imply a large number of destinations at the network layer. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Nov 26 11:03:03 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8C128C225; Wed, 26 Nov 2008 11:03:03 -0800 (PST) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADEA28C225 for ; Wed, 26 Nov 2008 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.95 X-Spam-Level: X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZa5PuZsFrvz for ; Wed, 26 Nov 2008 11:03:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7CC2B28C1F1 for ; Wed, 26 Nov 2008 11:02:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,670,1220227200"; d="scan'208,217";a="26915156" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2008 19:02:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQJ2pJu032398 for ; Wed, 26 Nov 2008 20:02:51 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAQJ2phT020843 for ; Wed, 26 Nov 2008 19:02:51 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 20:02:51 +0100 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 20:02:50 +0100 Message-Id: <73129E7A-4A8B-4F77-9640-3638374A65E9@cisco.com> From: JP Vasseur To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 26 Nov 2008 13:05:19 +0100 References: <20081120000002.2CAC93A6BD3@core3.amsl.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 26 Nov 2008 19:02:50.0951 (UTC) FILETIME=[94410570:01C94FF9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8897; t=1227726171; x=1228590171; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20I-D=20Action=3Adraft-ietf-roll-home-ro uting-reqs-06.txt=20 |Sender:=20; bh=sEC2L0lRTnMKjAqVNHbqR5S0sWEXOS2bYshuM5PGuNA=; b=Wk9aGmF00Duu/wossVKUNWxR+PmSihnBMmmj3ZBqXvW8hFZNoaGzXofGmj xfJcwcpzwkYC00oT94WztxMaKR9GQ6yOUMzL8f/bVgeCe9cHMgU6EBkj7fgM VfybHIwwjf; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-home-routing-reqs-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1254857904==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1254857904== Content-Type: multipart/alternative; boundary=Apple-Mail-43-285816404 --Apple-Mail-43-285816404 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Just a few references issues to be fixed before publication request. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: November 20, 2008 1:00:02 AM CEST > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-home-routing-reqs-06.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Home Automation Routing Requirements in Low Power > and Lossy Networks > Author(s) : G. Porcu > Filename : draft-ietf-roll-home-routing-reqs-06.txt > Pages : 17 > Date : 2008-11-19 > > This document presents home control and automation application > specific requirements for Routing Over Low power and Lossy > networks (ROLL). In a modern home, a high number of wireless > devices are used for a wide set of purposes. Examples include > actuators (relay, light dimmer, heating valve), sensors (wall > switch, water leak, blood pressure) and advanced controllers. > Because such devices only cover a limited radio range, routing is > > > often required. The aim of this document is to specify the routing > requirements for networks comprising such constrained devices in a > home control and automation environment. > > > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" > in this document are to be interpreted as described in RFC-2119 > [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-43-285816404 Content-Type: multipart/mixed; boundary=Apple-Mail-44-285816405 --Apple-Mail-44-285816405 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Just a few references issues to = be fixed before publication = request.

JP.

Begin forwarded = message:

Date: November 20, 2008 1:00:02 AM = CEST
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-home-routing-reqs-06.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : Home = Automation Routing Requirements in Low Power and Lossy Networks
Author(s) =       : G. Porcu
Filename =        : = draft-ietf-roll-home-routing-reqs-06.txt
Pages =           : = 17
= Date =            : = 2008-11-19

This document presents home control and automation = application
specific requirements for Routing Over Low power and = Lossy
networks (ROLL). In a modern home, a high number of wireless =
devices are used for a wide set of purposes. Examples include =
actuators (relay, light dimmer, heating valve), sensors (wall =
switch, water leak, blood pressure) and advanced controllers. =
Because such devices only cover a limited radio range, routing is =


often required. The aim of this document is to specify the = routing
requirements for networks comprising such constrained = devices in a
home control and automation environment. =  



Requirements Language

The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document = are to be interpreted as described in RFC-2119
[RFC2119].

A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routi= ng-reqs-06.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is = the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-44-285816405 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-11-19155513.I-D@ietf.org>

--Apple-Mail-44-285816405 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-44-285816405-- --Apple-Mail-43-285816404-- --===============1254857904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1254857904==--