Re: [core] sleepy to sleepy communication I-Ds

[Thomas Fossati <[e-mail]>]

Hi Jari,

On Mar 4, 2012, at 11:05 PM, Jari Arkko wrote:
> I liked the resource model in draft-vial better, because it seems so straightforward from a REST point of view. POST to get an ID from the proxy, PUT to update. In particular, it is easy for me to understand how the URIs get constructed and where traffic is routed. A random client somewhere else on the Internet knows how to go to mirror.example.net/17/temp. I don't necessarily understand how the same thing happens in draft-giacomin, can you expand on that?

you mean using the Publish option ?  If so, the random client uses the same URI that is associated to the sleepy resource (whose existence is pretty safe to be assumed in a REST environment) and asks the proxy acting as the delegated origin to serve it via Proxy-URI.  So, communication is pretty straightforward; discovery could be more tricky because I fear it necessarily goes through an RD -- i.e. discovery via /.well-known/core may not work (I have expanded a bit on this in the following.)

> In conclusion it seems that we have a architectural choice ahead of us. We could have sleepy nodes delegate their web existence to other nodes (like draft-vial does), enabling both other devices in the same network and devices elsewhere in the Internet to interact with mostly the other node. Or we could build support to COAP and proxies for mediation between sleeping nodes (like draft-giacomin and draft-fossati does). At the high level, the effects are similar but there are significant differences in details. I confess that I like the former model better, because it separates the support for sleepy nodes from whatever is needed by nodes interacting with them. But we probably don't understand the design space well enough yet to make a real decision. At least I certainly don't.

And we neither :-)

We are just trying to explore the problem space by using a bunch of different strategies.  We play with one rule (use the proxy as a mediator), and one constraint (stay in CoAP).

I think that the second is especially important, because it allows us to see how much we can achieve using just the protocol semantics (and its self-extension facility, options).

That's where we can hit interesting flaws and strengths of CoAP.

E.g., differently from HTTP, we have an explicit Proxy-URI object (which BTW is a wonderful thing): let's try to see how much can be said with it, for example doing origin delegation without having to create multiple different 'same resource' identifiers through mirroring.

Another important thing we are going to hit this way is how discovery based on /.well-known/core is meant to go through proxies.  AFAIK both core and link-format I-Ds are rather succinct on this matter, and even if it seems reasonable to assume that the /.well-known/core resource is both query-able through, and cacheable by, a proxy, perhaps the facts are not very much so.  We seem too much often to assume that the "well-known" interface relies on the resource authority being defined by the source address of the UDP packet carrying the response.  If so, querying the well-known interface (especially multicast) through a Proxy-URI has little hope to be fully functional.  We are sort of abusing an implicit L3 locator as the identifier of the resource authority, which makes "well-known" discovery generally incompatible with proxy mediated communication, unless each target URI in a link is given as a URI and not as a relative-ref (a thing that would be nice to discuss somewhere in the spec, perhaps the DNA I-D by Peter, Kerry and Anders is the right place ?)


To cut a long story short, I don't really know if we are better off establishing a new component like the MP proposed by Matthieu, or extend the base spec with one or more options that give the proxy new ad hoc capabilities.  The important IMHO is to keep on pushing our two (complementary) approaches as much as possible until, as you've said, we reach a better understanding of the matter that can inform a wise choice.

Thomas.

PS: It may also turn out that REQ3 of draft-shelby-core-coap-req is not an application layer issue! ;-)