Subject: Re: [dispatch] Review of draft-jimenez-p2psip-coap-reload

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 3 Nov 2014 16:51:35 +0000

Dear Gonzalo and Jaime,
dear list

Thanks for your comments, they really helped to get the whole idea. I think it would improve the draft when the introduction clearly explains the layering (by also providing use cases) and lists the features that CoAP will use from RELOAD (e.g., caching and that DNS becomes obsolete and that the addresses are resolved in a completely different way).

I think I will need this update to better understand some of the described features. The caching and discovery mechanisms do not appear to be compatible with the normal CoAP mechanisms. I think from a programmers point of view, this abstraction should be transparent, that is, the programmer can use the same CoAP APIs and make the same requests to achieve application goals as if there was no RELOAD network underneath. Maybe this is the case, but it is hard to see with all the new IANA considerations :)

The main technical issue is then the use of URIs. Since they mean something completely different in this draft, they need their own scheme. A look at the alternative transports in CoRE might help here, but it was also their main issue and I currently do not know if it is resolved yet.

A secondary issue is the integration with resource directories. I think, it would be good if normal RDs and RELOAD-RDs could coexist and link to each other. This would mean they use the same mechanisms
BTW: Normal RDs are not distributed in the P2P sense, but they can be mirrored and distributed like DNS servers.

I also stumbled upon this paper, which proposes a similar approach:
http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?tp=&arnumber=6899579
Are you aware of this work? Maybe there is something useful that can be included in the draft.

Best regards
Matthias

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 10 Nov 2014 09:09:56 +0000

Hi Matthias,

Thank you for the comments, I still haven’t modified the draft but I will take them into account and forward you the modified version as soon as it is done. 

Now regarding the link to the paper you forwarded. I have briefly scanned through it and what they proposed is similar to our draft and even more similar to our paper in 2012 (http://link.springer.com/article/10.1186%2F1687-1499-2012-121) and the DRD draft (http://tools.ietf.org/html/draft-jimenez-distributed-resource-directory-00.html). Of course now in late 2014 their approach introduces a lot of new things from CoRE that we did not have back then. Seeing that other people come up with this problem and similar solution is encouraging to try to work on it some more.

The basic principle of having a distributed network of WSN islands is the same as in our work. They also rely on a gateway that acts as CoAP server/client/http proxy/…and as a local RD on behalf of other CoAP EPs in the WSN. They use the .well-known to link the EP resources to the .well-known on the GW, which makes sense.  The different part is that they use two different DHT systems: DGT and DLS, the GW has to be a peer on both of them. DGT ads the GPS coordinates to the mapping, making discovery bind to the location of the device, this means that in mobility scenarios it would not work alone. That is why they also use DLS in parallel, to also have name resolution. 

In our draft we are only looking at the second case, and we already do it very similarly as they do using DLS. Another issue is that we are trying to marry RELOAD and CoAP, not only DHTs and CoAP. RELOAD has its own quirks so I would suggest to keep the two differentiated even if they are similar. However it would be great to have people collaborate on DRD too.

Ciao,
- - Jaime Jimenez