Re: [Roll] P2P-RPL: Data-Option in P2P-DIO

"Reddy, Joseph" <jreddy@ti.com> Mon, 04 June 2012 04:29 UTC

Return-Path: <jreddy@ti.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC14B21F87A1 for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 21:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0shwP05EGaqJ for <roll@ietfa.amsl.com>; Sun, 3 Jun 2012 21:29:54 -0700 (PDT)
Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by ietfa.amsl.com (Postfix) with ESMTP id EF19021F879C for <roll@ietf.org>; Sun, 3 Jun 2012 21:29:53 -0700 (PDT)
Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id q544Tqlg007661; Sun, 3 Jun 2012 23:29:52 -0500
Received: from DFLE70.ent.ti.com (dfle70.ent.ti.com [128.247.5.40]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q544Tql7020304; Sun, 3 Jun 2012 23:29:52 -0500
Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Sun, 3 Jun 2012 23:29:53 -0500
From: "Reddy, Joseph" <jreddy@ti.com>
To: Mukul Goyal <mukul@uwm.edu>, "roll@ietf.org" <roll@ietf.org>, "Jakob Buron (Jakob_Buron@sigmadesigns.com)" <Jakob_Buron@sigmadesigns.com>
Thread-Topic: P2P-RPL: Data-Option in P2P-DIO
Thread-Index: AQHNQTf+HlDbzHR71UaFCzCJbquvvpbpkbLA
Date: Mon, 04 Jun 2012 04:29:51 +0000
Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB37@DLEE10.ent.ti.com>
References: <6CD8B4189A89EB4FB816FA9827F6F65F0ABCD132@cph-ex1> <1105562878.579687.1338693679499.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <1105562878.579687.1338693679499.JavaMail.root@mail17.pantherlink.uwm.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.170.170.90]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jun 2012 04:29:55 -0000

Hi Jakob,

If we agree to  remove the sequence numbers from the data option ( and, consequently, require that the Origin must not modify the data-option during a transmission ), that would be acceptable to me.

-Regards, Joseph


----- Forwarded Message -----
From: "Jakob Buron" <Jakob_Buron@sigmadesigns.com>
To: "Joseph' 'Reddy" <jreddy@ti.com>, "Mukul Goyal" <mukul@uwm.edu>
Cc: roll@ietf.org
Sent: Tuesday, May 29, 2012 8:24:03 AM
Subject: RE: P2P-RPL: Data-Option in P2P-DIO

Hi, please see my comments inline.

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf 
> Of Reddy, Joseph
> Sent: Friday, May 25, 2012 11:08 PM
> To: Mukul Goyal
> Cc: roll@ietf.org
> Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO
> 
> Hi Mukul,
> 
> See response below...
> 
> -Regards, Joseph
> 
> -----Original Message-----
> 
> [Joseph]
> Section 9.4
> Bullet 1:
> Under what conditions would a router receive the same DIO and a Data- 
> Option with higher sequence number? I assume that only the Originator 
> can include a Data-Option ? Same question also arises for section 9.5 
> ( para
> 1 )
> 
> [Mukul]
> Yes, only the origin can include a data option for delivery to the 
> target(s). In theory, the origin might have newer data to convey to 
> the
> target(s) while the route discovery is still going on. Sequence 
> numbers accounts for that possibility. Note that Data option did not 
> have a sequence number earlier (before the first LC). Then, Pascal 
> raised the possibility what if origin changes the data option. How 
> would intermediate routers and target know that this is the newer 
> data? Hence, we introduced the sequence number.
> 
> [Joseph]
> I don’t think the Origin should able to this. In fact, the Origin must 
> not make any changes to the contents of the DIO and retransmit it 
> without updating the version number. If the Origin wants to send data, 
> it should simply wait until the p2p route is setup and then use it.
> 
> The whole idea of sending UDP Data messages in the ICMP message 
> payload itself doesn’t seem quite right. It is also not simple from an 
> implementation perspective to make this kind of cross layer interactions.
> 
[Jakob]
I understand the concern about the Data Option and cross-layer interactions. I also believe that it is a sensible and necessary design choice for home automation networks. Home automation frequently requires low-latency messages to be delivered to targets for which the originator has no route. An example is a remote light switch that needs to control a relocated lamp. The fastest way to do that in a reactive routing scheme is to piggyback the data on the routing packets. The other option would be to use simple flooding, with no trickle control, which would involve generating a huge number of packets. Piggybacking data on routing packets helps avoid generating extra packets.

Home automation networks do not need to update the Data Option while a discovery is in progress. I am okay with removing the sequence numbers if they add too much complexity.

Best regards,
Jakob
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll