Subject: [core] CoAP Topology Discovery (was Re: Proxy and server on the same port)

From: Peter Bigot <[email-masked]>
Date: Tue, 23 Nov 2010 07:35:33 -0600

More subject changing to keep threads separate.

OK, I think I see what you're after.  In my opinion, this is not a CoAP
protocol problem, but a network management problem related to CoAP traffic.
The same issue ought to translate to HTTP which also has application-level
gateways, and I would look for an existing solution in that domain.

If there isn't one for HTTP, but one is needed for CoAP and it is done using
CoAP rather than SNMP or some other mechanism, off-hand I'd suggest defining
a standard resource like coap://authority/topology that could be used as an
entrypoint to introspect the network topology and features including
gateway, proxy, and cache functions.  I think this would be a separate
document, incorporating the functionality you describe below.

Two slightly related issues:

Rather than standardize the hier-part of the URI to locate this function,
I'd propose adding a link relation that would allow it to be placed without
globally limiting how servers manage their resource namespace.
Alternatively, put it in /.well-known/core/topo, but that would require that
the link description resources be pushed down a level to something like
/.well-known/core/ld as the root.  Which is worth considering in a different
thread.

Sleeping nodes might be identified by a link parameter
"sleeping=<duty_cycle_description>" in their link descriptions on the
end-point identified by the authority part of the standard URI used to
access their resources (presumbly hosted on an always-awake endpoint).  I
don't think the link format document needs to define that parameter; it
should be part of the sleeping node solution, which might also introduce a
standard resource for management that normal clients don't need to know
about.

Peter

On Tue, Nov 23, 2010 at 7:16 AM, Anders Brandt <[email-masked]> wrote:

>  Hi Peter
>
> > From my perspective: why do you need to know?
>
> One one hand I agree with you. When rootcausing an issue in my network I
> may like to know...
> I imagine my gateway just returns "/caching=TRUE" (Zach may come up with a
> one-letter code for this standard path)
> The example of going to coap://chicagocacher in a sort of redirect was not
> what I was looking for. My main intention is (as stated in the CoAP spec):
> 1) to save network bandwidth, 2) discover sleeping nodes
>
> >...  Then the issue is how does it find out that chicagocacher exists and
> supports this sort of operation.
> > That's a service discovery and resource discovery issue.
>
> Agree 100%
> My main reason for responding is exactly discovery.
> For achieving a plug-and-play experience across subnets I have a need for
> identifying gateways and asking them what interfaces they have on their
> other side. Then I can go ask these interfaces to report local CoAP hosts,
> and so on. Every time, these hosts may be cached or discovered on demand via
> multicast if relevant.
> This can be done in a hierarchical, de-centralised fashion where no
> gateways have to store any information
> that is already stored in other gateways.
> Only the client running the discovery will get the full picture of all
> nodes in all subnets.
>
> Do you follow me?
> Thanks,
>   Anders
>
> ------------------------------
> *Fra:* Peter Bigot [mailto:[email-masked]]
> *Sendt:* ti 23-11-2010 05:46
> *Til:* Anders Brandt
> *Cc:* Klaus Hartke; core
>
> *Emne:* Re: [core] Proxy and server on the same port
>
> From my perspective: why do you need to know?
>
> The client should transmit a request for data from a URI to some other node
> (either a proxy, or an end-point extracted from the URI authority).  If it
> has "freshness" needs, it should incorporate a Max-Age option.  Whether the
> response comes from the origin server or a cache somewhere between the
> client and the origin server should not be detectable by the client.
>
> An alternative model is to allow applications to be made aware of something
> that caches resource values and provides access to them through a different
> URI; e.g. if the client thinks that coap://bigben/temperature is too far
> away, it might GET coap://chicagocacher/bigben/temperature.  Then the issue
> is how does it find out that chicagocacher exists and supports this sort of
> operation.  That's a service discovery and resource discovery issue.
>
> Peter
>
> On Tue, Nov 23, 2010 at 2:31 AM, Anders Brandt <[email-masked]> wrote:
>
>>   > So you do agree with what was in that email?  I assumed the complete
>> lack of response meant nobody thought it relevant.
>> Actually, this thread is very relevant.
>> I am currently investigating CoAP multi-subnet environments with sleeping
>> nodes and I am very much in favor of a precise terminology.
>>
>> Unfortunately I am still not 100% up to speed on CoRE. What is the
>> preferred way of indicating that a node (typically the default gateway)
>> provides caching on behalf of other servers in the same subnet? and in
>> another subnet?
>>
>> Thanks,
>>   Anders
>>
>> ------------------------------
>> *Fra:* [email-masked] på vegne af Peter Bigot
>> *Sendt:* ma 22-11-2010 10:53
>> *Til:* Klaus Hartke
>> *Cc:* core
>> *Emne:* Re: [core] Proxy and server on the same port
>>
>>   On Mon, Nov 22, 2010 at 11:22 AM, Klaus Hartke <[email-masked]> wrote:
>>
>>> Peter Bigot wrote:
>>> >> I think it makes a lot of sense to distinguish between end-points that
>>> >> act on behalf of a client and those that act on behalf of a server.
>>> >> Not sure what needs to be discussed (apart maybe from the actual terms
>>> >> used for the two roles).
>>> >
>>> > Just that I proposed completely rewriting section five to get CoAP to
>>> use
>>> > specific terms in the way I described in my email, which would result
>>> in a
>>> > significant change (clarification) to what "proxy" means, and a
>>> separation
>>> > of it from the concept of a "cache".  Your comment above is not the
>>> same
>>> > thing, and since nobody else has commented I don't think my email
>>> should be
>>> > the basis of a ticket.
>>>
>>> I thought my comment above would capture the essence of your email,
>>> but apparently it didn't.
>>
>>
>> Sorry,  I didn't read it that way.
>>
>>
>>> So here's an attempt at a more complete
>>> summary of your email:
>>>
>>> * Intermediary CoAP end-points act as both a client and a server in
>>> order to forward, with possible translation, requests and responses.
>>>
>>
>> OK.
>>
>> * A proxy is an intermediary selected by a client. A client can
>>> delegate all CoAP requests it can't do itself to a proxy.
>>> Configuration of this proxy for a particular node is an administrative
>>> function outside the scope of CoAP.
>>>
>>
>> Yes.
>>
>> * A gateway (a.k.a., reverse proxy, big brother, ...) is an
>>> intermediary imposed by the origin server to support sleeping nodes or
>>> perform any other role that might be hidden behind the authority part
>>> of a URI.
>>>
>>
>>  Almost; the origin server may be unaware of the presence of a gateway.
>> The network may impose the gateway.
>>
>> * Caching in turn is a function that may be paired with a proxy or
>>> with a gateway, but is not inherently coupled to either one.
>>>
>>
>> Yes.
>>
>>
>>> Please correct me if I'm missing something essential.
>>>
>>
>> Not at first glance,
>>
>> So you do agree with what was in that email?  I assumed the complete lack
>> of response meant nobody thought it relevant.
>>
>>
>>> > In what I proposed, a client is specifically configured to use a
>>> (single)
>>> > proxy, and that proxy is providing specific enhanced services on behalf
>>> of
>>> > the client.  With that model it makes little sense to accommodate
>>> placing
>>> > the proxy at the same end-point (port) as a normal server.
>>> >
>>> > However, if there's no buy-in for that change, and there's some
>>> compelling
>>> > reason why we should accommodate two applications at a single port, I
>>> > suppose a set of rules to use UriScheme values as a cue to whether a
>>> request
>>> > might have been intended for a proxy or a server could be made to work.
>>> > "Don't do that" seems like a better approach, in my opinion.
>>>
>>> There are two things:
>>>
>>> 1. Does it make sense to run a proxy and a server on the same port?
>>>
>>> The answer is probably: No.
>>>
>>
>> Good.
>>
>> 2. What to do when a client thinks an end-point is a server when it's
>>> actually a proxy?
>>>
>>
>> Ah.  I lost the context from the earlier parts of the thread, and assumed
>> your proposal was a way to allow dual-use.  In fact, your rules seem to be a
>> complete workable solution that does allow dual use.  Nice.  That's not what
>> raised my hackles.
>>
>> The solution is to have the client say what it thinks, so that its
>>> wrong assumption can be pointed out by the recipient.
>>>
>>
>> That is a good solution.  But in the details, I think it would be more
>> clear if the client does say what it thinks (that it's talking with a
>> proxy), rather than creating complex rules on how to interpret Uri-Scheme to
>> infer that it thinks it's talking with a proxy.  So use a new option named
>> Uri-Proxy with no value, the presence/absence of which indicates the
>> client's expectations.  Don't overload Uri-Scheme to mean something weird
>> that could conflict with future use, e.g. putting a coap and a coapm
>> (multicast) service on the same port.
>>
>> Change Uri-Scheme to Uri-Proxy in your proposal and you've got a solution
>> that allows disambiguation while at the same time allowing both functions to
>> occur on the same port and not muddying what Uri-Scheme means.  That's the
>> sort of approach I like: one technique that solves multiple problems
>> without introducing new ones.  Barring some undiscovered flaw, I'd support
>> that.
>>
>>
>>>
>>> Klaus
>>> _______________________________________________
>>> core mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>>
>>
>