Re: [dnssd] Provisional agenda for IETF98

It might be useful to collect some operational data on this.   My experience is that "duplicate" devices are always the same device appearing either sequentially or simultaneously on two different links.   Defending the name therefore has the effect of causing the device to constantly rename itself, so that it never has a stable name.   This really sucks from a usability perspective.   Having the service simply mark duplicate names, rather than defending them, seems more likely to work.   This is what we suggest in the simple homenet naming architecture draft.

> On Mar 20, 2017, at 4:07 AM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
> 
> On 19 Mar 2017, at 22.26, Stuart Cheshire <cheshire@apple.com> wrote:
>> 8. Zone Stitching — when clients can interrogate multiple links (e.g., via a Discovery Broker) it would be convenient if we did not have names duplicated on the different underlying links. I confess that I still don’t have a single blindingly-obvious answer to this, so I welcome discussion and suggestions. I suspect the solution might build on the Discovery Proxy. When two links are configured to not allow duplicated names, the two Discovery Proxies in question would establish a bidirectional TCP connection. When one Discovery Proxy sees a device ask (using Multicast DNS) “Is this name in use?” the Discovery Proxy would ask its peer (over the TCP connection) “Is this name already in use on your link?” and if the answer is “Yes”, then the Discovery Proxy tells the local device (using Multicast DNS) “Name already in use; pick another.”
> 
> I have thought quite a bit about this over the years (less recently, as I am mostly working on non-IETF stuff).
> 
> I am not very fond of discovery proxies talking with each other; you wind up with O(N^2) connections given N links. 
> 
> Instead, I would probably do this as function of discovery broker; either
> 
> a) it provides rewritten information to its clients (somewhat fishy, as if mdns info contains computer-42, and there is another computer-42, you would wind up with e.g. computer-42-2 for one of them)
> 
> b) discovery broker <> discovery proxy action is actually bidirectional, and DB can tell DP to force client to rename.
> 
> Either design is relatively simple given devices that do not move. 
> 
> However, in presence of moving devices, I am somewhat uncertain on what is the correct way; as device moves, it gets new IP address, so how to correlate that X.link1.example.com is actually X.link2.example.com? I can think of few obvious heuristics but given recent work in IPv6 address pseudorandomization per link, they seem error prone and therefore not advisable. Therefore I am currently leaning towards design
> 
> c) DB just shows (DNS-SD) services, even if they are duplicate (omitting extra ones?), and they point to host names on various links that may not be unique. In other words, just omit conflict resolution across links.
> 
> or even
> 
> d) DB just shows (DNS-SD services) for each link; based on cursory reading of RFC 6763, nothing prevents PTR _http.tcp.example.com => site on X._http._tcp.link1.example.com
> 
> I am not quite sure if d) is valid, but at any rate, I am really leery of options a and b currently due to how they interact (or actually do not interact _well_) with moving hosts.
> 
> Cheers,
> 
> -Markus
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd