Re: [dnssd] Unicast Service Discovery Autoconfiguration

Exactly. Which is why it’s important to only use it in cases where either it can be detected or it doesn’t matter if loss happens.

There is a mechanism to detect if autoconfiguration doesn’t work for IPv6.

I’m not aware of a mechanism to detect if you don’t receive a service advertisement with mDNS.

Thanks,
Tom

> On Nov 8, 2018, at 4:54 PM, Joe Touch <touch@strayalpha.com> wrote:
> 
> UDP isn’t reliable, period. Retransmit. 
> 
>> On Nov 8, 2018, at 1:10 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>> 
>> If multicast packets are dropped during IPv6 configuration, you won’t get an IPv6 address and you won’t be able to communicate via IPv6. This is easy to detect. When multicast packets are lost during busy periods on wifi and services are not reliably discovered, there’s no easy way to detect this.
>> 
>> On busy wifi networks, multicast just isn’t reliable.
>> 
>> See https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03
>> 
>> Tom
>> 
>>> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
>>> 
>>> Hi Stuart, et al.,
>>> 
>>> I’m confused by the text below; given IPv6 configuration relies on multicast, why is it not reasonable to assume similarly useful multicast here?
>>> 
>>> Joe
>>> 
>>>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> wrote:
>>>> 
>>>> Here is a link to the new draft Ted Lemon and I wrote as a result of our work at the Hackathon here at IETF 103.
>>>> 
>>>> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>>>> 
>>>> Here’s a brief summary of what the document is about:
>>>> 
>>>> Because multicast can be inefficient and unreliable, work is
>>>> taking place to enable DNS-Based Service Discovery to operate
>>>> with less reliance on multicast.  One current target use case
>>>> for this work is Thread wireless mesh networking.
>>>> 
>>>> Existing work describes how DNS-Based Service Discovery can
>>>> be performed using unicast on such a network.  Devices on
>>>> the Thread mesh offering services use Service Registration
>>>> Protocol to register their services at a Service Registration
>>>> Server.  Devices seeking to discover these services send
>>>> unicast queries to the Service Registration Server using
>>>> unicast DNS for single individual queries, and using DNS Push
>>>> Notifications where ongoing change notification is required.
>>>> 
>>>> For proof-of-concept experiments, the necessary information can
>>>> be configured manually, and this has been done successfully.
>>>> For deployment, we need to determine how the necessary information
>>>> will be learned and configured automatically in real-world scenarios.
>>>> 
>>>> Stuart Cheshire
>>>> 
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> dnssd@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>> 
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>> 
> 