Re: [dnssd] CoAP resource discovery and DNS-SD

[Toerless Eckert <[e-mail]>]

To discover a service via mDNS is not not necessarily quite LLN friendly.

You need to query/reply for all the RR involved in a service, which is
if i remember AAAA, SRV, PTR, TXT and maybe CNAME. Admittedly
i have not tried to work out how many bits this is, but there is
also the question of how many packets this will end up being in the
widey deployed implementations and who takes care of minimizing/optimizing
that. So there is a cost to this more comples layering. RRs, messages, packets.

In coap, like in GRASP, we can map all necessary service elements into
a single message, so we know it is a single request/reply exchange.

Yes, i would definitely prefer to minimize the amount of multicast,
especially given how those LLN can really only flood them across
the whole network, but both DNS and COAP could be on par in that
department. 

Due to the proprietary nature of Thread i have not been able to figure
out how it proposes to instantiate and discover the server instances
of DNS or COAP that should be used. But thatss also where another
complexity can come in:

                                    coap/dns
                                    server                             coap/dns
      client .... 802.15.4-net .... border-rtr .... ent-networks ..... server
                                                       ...
                                                     service-server

The server we may want to discover on the client may not necessarily be
connected to the 802.15.4 network, but the enterprise network behind it,
(most simple designs would hope/expect for the service we want to use to
 be running on the border-rtr).

So, it seems to me i need some form of scoping of service/resource
request/replies from clients between those that should be only
resolved within the 802.15.4 network, and those that should resolve
(also) across the ent-network behind it. I am not quite sure how
to most easily do this, but off the top of my head it looks as
if i wanted some simple proxy function on the border router which
on a per-service/resource basis decides whether to forward the request
upstream to the coap/dns server in the enterprise network or not.
And with coap i can see how that proxy function is easily implemented,
and the concept of such a proxy is discussed in coap.

Replicating that functionality in DNS would be quite more complex i fear.

Cheers
    Toerless

On Fri, May 13, 2022 at 08:01:37PM -0400, Ted Lemon wrote:
> The registry/mapping problem is where we fell down. Why are you trying to
> use Core for this anyway? DNS-SD works fine—that’s what we’re using for
> Thread, for example. You can just do a DNS UDP query or use DNS Push rather
> than using multicast if you use SRP to update the DNS server.
> 
> On Fri, May 13, 2022 at 19:57 Toerless Eckert <[e-mail]> wrote:
> 
> > Thanks, Ted
> >
> > Any pointer to Kerry's work in this regard ? I was looking through her
> > expired
> > draft, but i didn't see anything getting to that exact point
> > (draft-doi-core-parameter-option looks like related, but i can't really
> >  make heads or tails out of it).
> >
> > So lets say:
> >
> > REQ: GET /.well-known/core?rt=<resource>
> >
> >      RES: 2.05 Content
> >      Content-Format: 40
> >      Payload:
> >      </b>;rt=<resource>;p=<prio>;w=<weight>;proto=<string>,
> >      ...
> >
> > I am just defining in the spec for my resource that it has additional
> > option
> > link-target attributes. p= for a numeric priority value, w= for a numeric
> > weight attribute and proto= for a string enumerating protocol details.
> > And these are the same parameters as what i'd use for the same resource
> > (oops: service) when using DNS-SD.
> >
> > It seems as if rfc6690 didn't actually create a registry for those
> > link-targets
> > but simply created rt= and if= link-targets and just created a registry for
> > the values of rt= and if=. Which raises the question if i could simply
> > specify p/w/proto to be normative in the context of the specific resource,
> > and if not whether those addtiional link-targets would have to be
> > specified as
> > updated to rfc6690...
> >
> > Cheers
> >     Toerless
> >
> > On Fri, May 13, 2022 at 07:22:41PM -0400, Ted Lemon wrote:
> > > We were never able to figure that out either. The mapping from Core RD in
> > > particular to DNS-SD is something that the DNS-SD working group actually
> > > pursued for a while (Kerry Lynn worked on this pretty heavily for about a
> > > year).
> > >
> > > On Fri, May 13, 2022 at 7:20 PM Toerless Eckert <[e-mail]> wrote:
> > >
> > > > Dear CoAP WG
> > > >
> > > > I am trying to figure out how to use CoAP discovery as specified in
> > RFC7252
> > > > (and expanded in rfc6690 and rfc7390),  but i can not figure out how
> > > > one would encode basic parameters of a resource, such as those
> > supported
> > > > in DNS-SD, rfc6763:
> > > >
> > > > When discovering more than one instance of a resource, such as
> > possible,
> > > > when using multicast discovery as on rfc7252, clients will have to
> > figure
> > > > out,
> > > > which instance of a resource to select. DNS-SSD has priority and weight
> > > > parameters associated with each instance. How would one describe/encode
> > > > such instance and weight ?
> > > >
> > > > When discovering one or more instance via DNS-SD, the discoering client
> > > > may further select the best instance in terms of interoperability,
> > > > functionality
> > > > and performance based on one or more key=value property pairs
> > describing
> > > > the instance. How is this done in CoAP ?
> > > >
> > > > Thanks a lot!
> > > >
> > > > Toerless
> > > >
> > > > _______________________________________________
> > > > dnssd mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dnssd
> > > >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]