Subject: [dnssd] Unicast Service Discovery Autoconfiguration

From: Stuart Cheshire <[email-masked]>
Date: Thu, 08 Nov 2018 14:27:24 +0700

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Nov 2018 07:35:24 -0800

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 <[email-masked]> wrote:
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 8 Nov 2018 16:10:47 -0500

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 <[email-masked]> wrote:
> 
> Hi Stuart, et al.,
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Nov 2018 13:54:43 -0800

UDP isn’t reliable, period. Retransmit. 

> On Nov 8, 2018, at 1:10 PM, Tom Pusateri <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Nov 2018 05:07:53 +0700

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 <[email-masked]> 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.
> >
> > See
> https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03
> >
> > Tom
> >
> >> 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
> >>
> >>> 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.
> >>>

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 8 Nov 2018 17:14:40 -0500

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 <[email-masked]> wrote:
>

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 8 Nov 2018 17:16:45 -0500

To be clear, when a service first advertises itself, it sends multiple copies of the advertisement (usually 2) to try to counter this loss potential. But after that, it only sends a single copy in response to a query.

Thanks,
Tom

> On Nov 8, 2018, at 5:14 PM, Tom Pusateri <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Nov 2018 15:03:33 -0800

> On Nov 8, 2018, at 2:16 PM, Tom Pusateri <[email-masked]> wrote:
> 

That appears to suggest that:

a) 2 is not necessarily enough in the first round
b) 1 is definitely not enough in later rounds

Unless you can explain why multicast is less likely to be successful at all (vs reaching ALL its intended recipients, which should not be required here), in which case that issue ought to be the focus.

Either way, it seems like a good place to start digging is in the current mechanism, at least before searching for a completely new one.

Joe

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 8 Nov 2018 18:18:24 -0500

No matter how many times you retransmit, you can’t be sure it is received over UDP. 

We already have a mechanism to ensure it’s delivered over TCP that also has well implemented encryption (TLS) and so I prefer this route and so do many others. 

Otherwise, we’re inventing a reliable multicast protocol and still don’t have a good solution for key exchange for encryption. 

Tom

> On Nov 8, 2018, at 6:03 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Nov 2018 15:27:00 -0800

> On Nov 8, 2018, at 3:18 PM, Tom Pusateri <[email-masked]> wrote:
> 

You can implement positive confirmation at the app layer.

> We already have a mechanism to ensure it’s delivered over TCP that also has well implemented encryption (TLS) and so I prefer this route and so do many others. 

DTLS will work with UDP; the benefit of UDP is that it can use native IP-level multicast where TCP cannot.

> Otherwise, we’re inventing a reliable multicast protocol and still don’t have a good solution for key exchange for encryption. 

Agreed. That’s been tried many times before without a good solution.

I’m just suggesting that sending a UDP packet once - or even twice - isn’t expected to be all that robust.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Nov 2018 06:34:00 +0700

This is true but irrelevant. Multicast isn’t a great solution anyway. Wakes
everyone up, not just who you are trying to reach.

On Fri, Nov 9, 2018 at 6:27 AM Joe Touch <[email-masked]> wrote:

> > We already have a mechanism to ensure it’s delivered over TCP that also
> has well implemented encryption (TLS) and so I prefer this route and so do
> many others.
>
> > Otherwise, we’re inventing a reliable multicast protocol and still don’t
> have a good solution for key exchange for encryption.
>

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 8 Nov 2018 18:59:07 -0500

> On Nov 8, 2018, at 6:27 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

We don’t want to invent a reliable multicast layer. There are a lot of corner cases and an IRTF group has been working on it for years.

> DTLS will work with UDP; the benefit of UDP is that it can use native IP-level multicast where TCP cannot.

DTLS doesn’t work with multicast and it’s not widely implemented.

> I’m just suggesting that sending a UDP packet once - or even twice - isn’t expected to be all that robust.

Can you tell us your best reason NOT to use TCP/TLS?

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Nov 2018 16:49:27 -0800

OK, maybe I’m confused — the doc appears to imply:

	- multicast doesn’t work for discovery
	- so here’s a unicast mesh instead

That seems broken to me. Multicast ought to be more than sufficient - even when unreliable - for discovery.

*once discovered*, sure, use TCP/TLS to exchange config info. But I didn’t get the impression that post-discovery config was the focus of the draft.

Joe

> On Nov 8, 2018, at 3:34 PM, Ted Lemon <[email-masked]> wrote:
> 
> This is true but irrelevant. Multicast isn’t a great solution anyway. Wakes everyone up, not just who you are trying to reach. 
> 
> On Fri, Nov 9, 2018 at 6:27 AM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Nov 8, 2018, at 3:18 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Nov 2018 07:55:27 +0700

Joe, multicast is much more lossy than unicast on most networks, has high
latency because of waiting for beacon intervals, and reduces overall
bandwidth. Are you saying that this is not a problem, or were you just
unaware of the issue?

On Fri, Nov 9, 2018 at 7:49 AM Joe Touch <[email-masked]> wrote:

> *once discovered*, sure, use TCP/TLS to exchange config info. But I didn’t
> get the impression that post-discovery config was the focus of the draft.
>
> Joe
>
> This is true but irrelevant. Multicast isn’t a great solution anyway.
> Wakes everyone up, not just who you are trying to reach.
>
>> > Otherwise, we’re inventing a reliable multicast protocol and still
>> don’t have a good solution for key exchange for encryption.
>>

---

From: James Andrewartha <[email-masked]>
Date: Fri, 9 Nov 2018 11:24:50 +0800

For Apple devices in particular, the wireless chipset will go to sleep
before receiving all broadcast/multicast packets. True since OS X 10.10,
I have the packet traces to prove it. The only solution is proxy ARP,
and that doesn't help with multicast.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 9 Nov 2018 12:09:14 -0500

Agreed. Auto-configuration in general is a use of multicast where loss can be detected (like in the IPv6 auto-configuration case) because the client either gets a response back or it doesn’t and it can retry.

In my opinion, this is a more acceptable use case for multicast discovery.

Let’s call it "ANY Discovery” and it has the following properties:

1. You can detect if you get an answer and retry if you don't
2. Any server can respond and provide complete information

Discovering servers where any number of similar but different services exist is not a good use of multicast discovery.

Let’s call this “MANY Discovery” and it exhibits the following properties:

1. You can’t detect if you get responses from ALL of the possible services
2. Any server responding typically only has partial information

But in Ted’s case, neither of these apply. He is more concerned with other inherent problems with wireless link layer multicast ethernet drivers such as excessive delay and power use.

Tom

> On Nov 8, 2018, at 7:49 PM, Joe Touch <[email-masked]> wrote:
> 
>> On Nov 8, 2018, at 3:34 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>