Re: [Roll] 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