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

[Ted Lemon <[e-mail]>]

Bear in mind that with dns name compression, you don’t repeat any domain
name—you just store a pointer for each subsequent repetition of the same
terminal label sequence. So default.service.arpa is a little longer, but
doesn’t multiply.

On Tue, May 17, 2022 at 17:28 Toerless Eckert <[e-mail]> wrote:

> Thanks, Esko
>
> Actually a client would discover a new service instance with quering the
> PTR RR,
> so rfc6763 12.1. is relevant, but yes, it does  ask to include all
> dependent RRs.
> Here is what i think is the minimum generic case for a single service
> instance with one locator address.
>
> _service-name._udp.local                        PTR
>  service-instance-name._service-name._udp.local
>  service-instance-name._service-name._udp.local SRV   prio weight port
> service-instance-locator.local
>  service-instance-name._service-name._udp.local TXT   'key=value;...'
>  service-instance-locator.local                 AAAA  IPv6-addr
>
> I have not tried to figure out how many bits that would be, especially in
> comparison
> to coap/core-link encoding.
>
> Actually, when one uses only unicast DNS and SRP, i guess you wouldn't
> use .local, but .default.service.arpa, which would make all the messages
> somewhat bigger
> (thinking about how the ANIMA REST URLs where explicitly shortened, but
> then DNS
>  adds the overhead back ...). I wonder how much of those details are
> better defined
> in the ANIMA drafts so that we do ensure interoperability...
>
> Cheers
>     Toerless
>
> On Tue, May 17, 2022 at 04:08:48PM +0000, Esko Dijk wrote:
> > Toerless, there was also the below point in your mail:
> >
> > > 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
> >
> > As I understand, it can be the same for DNS-SD. A good implementation
> would return the SRV record for found services and also the associated AAAA
> records to have a single request/response. RFC 6763 12.2 defines this.
> > I would add to such behaviour that if the number of answers is high then
> the implementation can shorten the response by leaving out the AAAA
> records. Something that a DNS-SD server / SRP server suitable for mesh
> networks use could do.
> >
> > (Of course it has the downside that in any case a client still MUST be
> prepared for the case that it doesn't receive the AAAA records in the first
> response. So in that sense client complexity is a bit higher than for e.g.
> CoAP / GRASP(?) )
> >
> > Regards
> > Esko
> >
> > -----Original Message-----
> > From: Esko Dijk
> > Sent: Monday, May 16, 2022 09:59
> > To: Toerless Eckert <[e-mail]>; Ted Lemon <[e-mail]>
> > Cc: [e-mail]
> > Subject: RE: [dnssd] CoAP resource discovery and DNS-SD
> >
> > Hello Toerless,
> >
> > Ted was referring to the Service Registration Protocol (SRP) for DNS-SD
> as defined by
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-13 .
> > This enables registration and discovery over generic services over
> unicast, similar to what a CoRE Resource Directory can do for CoAP
> resources.  A single request/reply exchange can be used to register a
> device's services.
> > Querying is the same as in unicast DNS-SD.
> >
> > For SRP you need of course a way to get an IP address of the / a SRP
> server before you can use SRP registration/querying. In OpenThread, this is
> done by e.g. including such address in mesh-network-wide  configuration
> data. So then all devices that may need this, have it.
> > See GetNextDnsSrpUnicastInfo()
> https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L262
> for details.
> >
> > There's also the possibility to include a more compact set of
> configuration data that enables a device (client) to reach an SRP server
> over an anycast address ; see e.g. FindPreferredDnsSrpAnycastInfo()
> https://github.com/openthread/openthread/blob/main/src/core/thread/network_data_service.cpp#L196
> .
> > Anycast reachability is useful for redundancy if multiple SRP servers
> are available and are kept synchronized (using e.g.
> https://datatracker.ietf.org/doc/html/draft-lemon-srp-replication-01).
> >
> > Some of the functions you mention may already be supported by the above
> approach. E.g. Thread defines mesh-local IPv6 addresses (described in the
> 'Thread Network Fundamentals' white paper) which would enable a device to
> advertise a particular service only in mesh scope, while other services
> could be advertised with greater scope by using a global or ULA IPv6
> address. And the proxy function you mention may not be needed if multiple
> synchronized SRP servers are used, or a single SRP server that serves all
> mesh networks plus all regular non-constrained networks in an installation
> site.
> > Note that proxying between mDNS devices and SRP-using devices is
> provided for (by
> https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy and
> rfc8766). Such that on-mesh constrained devices don't have to use multicast
> / mDNS.
> >
> > Regards
> > Esko
> >
> >
> > -----Original Message-----
> > From: dnssd <[e-mail]> On Behalf Of Toerless Eckert
> > Sent: Saturday, May 14, 2022 16:02
> > To: Ted Lemon <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [dnssd] CoAP resource discovery and DNS-SD
> >
> >
> > 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]
> >
> > _______________________________________________
> > dnssd mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnssd
>
> --
> ---
> [e-mail]
>