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

Mukul Goyal <mukul@uwm.edu> Fri, 25 May 2012 21:47 UTC

Return-Path: <prvs=485d12915=mukul@uwm.edu>
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 B893F21F880F for <roll@ietfa.amsl.com>; Fri, 25 May 2012 14:47:39 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvGPHIpz60p6 for <roll@ietfa.amsl.com>; Fri, 25 May 2012 14:47:39 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 10CE821F880E for <roll@ietf.org>; Fri, 25 May 2012 14:47:36 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAHr9v09/AAAB/2dsb2JhbABEhTazBCNWGw4MAg0ZAlkGiCCmEIk6iQSBJI4KgRIDiD+MWY9wgn4
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 986C9E6A8E; Fri, 25 May 2012 16:47:35 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2ti8AhPPFxy; Fri, 25 May 2012 16:47:35 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 69F2EE6A72; Fri, 25 May 2012 16:47:35 -0500 (CDT)
Date: Fri, 25 May 2012 16:47:35 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Joseph Reddy <jreddy@ti.com>
Message-ID: <183104642.520057.1337982455333.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA34066@DLEE10.ent.ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
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: Fri, 25 May 2012 21:47:39 -0000

Hi Joseph

Please see inline.

Thanks
Mukul


[Joseph1]
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 )

[Mukul1]
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.

[Joseph2]
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. 

[Mukul2]

I think that implementation concerns (regarding sending UDP data inside ICMP message) might be valid and would like to hear more opinions in this regard. But, I also think that LLNs need cross layer interactions and this experimental RFC might be the perfect place to check if this works or not. Certainly, the need to piggyback data on route discovery packets is real in many LLN applications. In my opinion, we should allow this unless there are overpowering reasons why this is a bad idea.