Re: [dnssd] Unicast Service Discovery Autoconfiguration

Joe, are you saying that the characteristics of UDP over multicast are
identical to the characteristics of UDP over unicast on all layer twos?
 Otherwise, I don't think you've made a useful point here.   Our experience
is that packet loss rates are on the order of 70% for multicast in crowded
environments (that is, where there is cross-interference between WiFi
networks, as is typical in a city).

On Fri, Nov 9, 2018 at 4:55 AM 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
> >
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>