Re: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt

[Bob Bradley <[e-mail]>]

> On Mar 10, 2019, at 10:53 PM, Christian Huitema <[e-mail]> wrote:
> 
> On 3/10/2019 9:55 PM, Bob Bradley wrote:
>> It looks like this is intended to find a specific server on the
>> network using that server's discovery key to encrypt the request. If
>> the client doesn't know which servers might be on the network, would
>> it need to send a multicast packet for each server it has a key for?
>> For example, if I'm paired with 20 devices then when discovery starts,
>> would I send 20 multicast packets?
> 
> As designed, the answer is yes, the client would send 20 packets. I
> understand very well that there is an alternative design in which the
> server sends a packet announcing its arrival, and then every interested
> client discovers the server and contacts it. I believe that the scaling
> is actually equivalent:
> 
> 1) In my design's worst case, the client sends N packets, and P servers
> who are present perform O(N) trial decryptions. Total O(P.N2).
> 
> 2) In the server announce design, P arriving servers send P packets upon
> arrival on the network, and O(N) clients perform N trial decryptions.
> Total O(P.N2) as well.

In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device.

As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then:

Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses.
Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.

> It is pretty hard to resolve that discussion without actual statistics,
> application scenario, etc. For example, it is not clear at all that
> "servers" will be listening all the time, versus listening only when the
> corresponding app is in focus, e.g. when several users start the same
> app and explain app instances to find each other.
> 
>> 
>> Are there plans for a mechanism to announce the availability of a
>> server? For example, if I start discovery (which sends an initial
>> batch of multicast packets) and then a few seconds later a server
>> becomes available, will server have a way to notify the client of its
>> availability?
> 
> Again, this depends a lot on application scenario. In a peer-to-peer
> scenario, the roles of server and client are flexible. Peer A comes
> first, finds nobody there, starts listening in server mode. Peer B
> arrives a moment later, starts in client mode, engages in discovery,
> succeeds.
> 
> -- Christian Huitema
> 
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd