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

From: "Reddy, Joseph" <[email-masked]>
Date: Fri, 25 May 2012 21:07:55 +0000

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.

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 25 May 2012 16:47:35 -0500 (CDT)

Hi Joseph

Please see inline.

Thanks
Mukul

[Joseph1]
Section 9.4
Bullet 1: 

[Mukul1]

[Joseph2]

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

---

From: Jakob Buron <[email-masked]>
Date: Tue, 29 May 2012 13:24:03 +0000

Hi, please see my comments inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reddy, Joseph
> Sent: Friday, May 25, 2012 11:08 PM
> To: Mukul Goyal
> Cc: [email-masked]
> Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO
> 
> Hi Mukul,
> 
> See response below...
> 
> -Regards, Joseph
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll