Subject: [dnssd] multicast over wireless links

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 10:53:19 -0400

All,

While IEEE 802.11 has known specific issues with IP multicasting,
most radio links (including SATCOM) actually are natively
broadcast links, hence perform multicasting efficiently.

As an example, for my clients with IP/VSAT deployments or 
other IP/RF deployments (for RF != 802.11), multicast is 
the MOST EFFICIENT way to communicate and unicast is the 
LEAST EFFICIENT way to communicate.

As I've said in other IETF working groups, it would be a 
mistake to optimise an upper-layer protocol for a specific 
link-technology.  Instead, folks ought to engage with 
IEEE 802.11 to help them find ways to more effectively
support IP multicast traffic.

So I object to any proposal to "optimise" DNS-SD for 802.11,
because the issues with 802.11 are unique to the design of
its MAC/LLC layer protocols.

Yours,

Ran Atkinson

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jul 2014 10:58:02 -0400

> its MAC/LLC layer protocols.

Do you envision DNS-SD being used on satellite networks?

---

From: Alf Watt <[email-masked]>
Date: Thu, 24 Jul 2014 09:21:50 -0700

RJ,

The particulars of 802.11 multicasting are significant to the mDNS & DNS-SD community for a few of reasons:

- the overwhelming popularity of Wi-Fi devices and networks for internet and service access
- the specific behavior of 802.11 radios transmitting at their lowest common rate for broadcast and multicast
- the overwhelming popularity of Apple's devices which rely heavily on these technologies on Wi-Fi networks

There is, in my opinion, a gap between the perceived impact of mDNS on network link performance and the reality, but perception is important as I know AP vendors who have imposed despotic multicast queuing regimes in order to 'manage' mDNS traffic on large networks, effectively breaking service discovery for large numbers of users.

It's certainly possible to use mDNS over other types of radio link, bluetooth PAN for e.g. so I agree that focusing solely on 802.11 would be misguided and that we should take other scenarios into account (the ZigBee Alliance for e.g uses mDNS and DNS-SD as well and has different multicast issues than 802.11 due to it's multicast forwarding architecture).

So, I think it's fair to say that we need to carefully consider the impact of mDNS and DNS-SD when used on a number of RF MAC/LLC protocols and make sure we have solutions which makes sense for the scenarios in which we want to support service browsing.

Best,
Alf

On Jul 24, 2014, at 7:53 AM, RJ Atkinson <[email-masked]> wrote:

> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 12:22:06 -0400

> Do you envision DNS-SD being used on satellite networks?

Yes.

I know of many IP/RF networks, including IP/SATCOM
but also other IP/RF other than 802.11, where DNS-SD 
both is desired and would be useful.

IP/SATCOM is commonly used today within a single
administrative domain to connect different sites
together.

Yours,

Ran

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Jul 2014 13:25:11 -0400

> administrative domain to connect different sites

Forgive me, but this doesn't sound like a valid use case for DNSSD.   It sounds like you are trying to use DNSSD to solve a problem that is actually out of scope, because you are attracted to the benefits that a multicast DNSSD solution would provide (which I agree exist).

But I think that this is a very specialized use case, and that the WiFi use case is a _much_ more important use case.   Asking IEEE to fix WiFi is not really a good approach to addressing the problem of inefficient multicast for existing deployments, and this work is intended to address existing deployments.

Therefore, I think that if we want to address this use case, the right way to do it is to come up with a mechanism for doing multicast distribution of DNSSD updates on broadcast-friendly networks, and not to just make this the default operational mode for DNSSD.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 14:01:28 -0400

On 24  Jul 2014, at 13:25 , Ted Lemon wrote:
> Forgive me, but this doesn't sound like a valid use case
> for DNSSD.   It sounds like you are trying to use DNSSD
> to solve a problem that is actually out of scope, ...

I totally disagree with your conclusion.  

Perhaps I have not been adequately clear about the
deployments ?  I'm happy to chat further in the 
hallway if you're around IETF.

Other than some links being made by VSAT terminals, 
the deployments are just like any other multiple
IP subnet enterprise deployment or just like a typical
university deployment.

> Asking IEEE to fix WiFi is not really a good approach
> to addressing the problem of inefficient multicast
> for existing deployments, and this work is intended
> to address existing deployments.

Well, in both 6MAN and v6ops, roughly the same issue with
the IEEE 802.11 MAC design has come up (e.g., in the context 
of IPv6 ND) and there has been a lot of pushback from multiple 
quarters on the idea that IPv6 ND ought to change to use less 
multicast -- and multiple suggestions from multiple parties 
that we need to engage with 802.11 to help them optimise their 
multicast support, rather than go change IPv6's current utter 
dependence on multicasting just because of a MAC design issue 
in one link technology.

> Therefore, I think that if we want to address this use case,
> the right way to do it is to come up with a mechanism
> for doing multicast distribution of DNSSD updates on
> broadcast-friendly networks,

...most deployed IP networks are broadcast-friendly
and IPv6 is designed around the belief that multicasting
is available and works reasonably well...

> and not to just make this the default operational mode for DNSSD.

I'd invert your suggestion.  

I'd say that by default we ought to stick with existing 
IP multicasting, in the ways it is used today (including,
for example, IPv4 mast, IPv6 mast, IPv6 ND, and mDNS), 
but that we could document an optional-to-implement &
optional-to-use link-specific optimisation that 802.11 
implementers could support to reduce the multicast use 
over the air.  

The key, in my mind at least, is that any optimisations
for 802.11 issues ought to be localised/isolated into
the 802.11 devices -- rather than being imposed on everyone.

In the IPv6 world, there has been some discussion (I think
the idea goes back to Fred Baker during 6MAN earlier this week, 
but perhaps I've got the attribution wrong) that perhaps 
802.11 base stations would cache and coordinate their ND 
transmissions, sending them periodically in a burst, for example.  
Something similar likely could help for mDNS/UDP/IP/802.11; 
after all, mDNS traffic is easy to identify for special treatment 
isolated *inside the wireless base station* -- and without 
adversely affecting everyone else.  

Yours,

Ran Atkinson

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Jul 2014 19:57:55 +0100

On 24 Jul 2014, at 19:01, RJ Atkinson <[email-masked]> wrote:

> <snip>

So for those who want to look at this, what was discussed in intarea and v6ops (we’ve had no 6man at this IETF) was based on presentations on the following draft:

http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00

My personal view is that what we design here should be consdirate of the multicast messaging load it may generate, but for those messages that are generated we may see lower layer optimisations being made for specific link types (for example the ‘bundling’ suggested above for 802.11) and those optimisations may (for example) affect the timeliness of delivery. The latter may reinforce the desirability of mechanisms such as DNS LLQ.
 
Tim

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 16:14:27 -0400

On 24  Jul 2014, at 14:57 , Tim Chown wrote:
>  (we’ve had no 6man at this IETF)

Tim,

My apologies for having an unclear antecedent.

This topic was discussed during 6MAN at IETF/London, 
for example with respect to the proposal by Erik Nordmark 
et alia to modify IPv6 ND to better suit 802.11 links.

Cheers,

Ran

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 24 Jul 2014 19:47:32 -0400

> On Jul 24, 2014, at 1:25 PM, Ted Lemon <[email-masked]> wrote:
> 
> Asking IEEE to fix WiFi is not really a good approach to addressing the problem of inefficient multicast for existing deployments, and this work is intended to address existing deployments.
> 

Having spent a good portion of my career on IP multicast (from Token Ring to IP Multicast VPNs), it baffles me how a radio can have such a difficult time doing IP multicast. The 802.11 link layer clearly needs improvement in this area. Access points regularly fall over dead when bridging an ethernet wired connection to wireless when there is a high data rate multicast stream (actually 4Mbps isn't that high). This is just unacceptable.

With most radios, multicast is the most efficient form of transmission. But in 802.11, every receiver in range currently receives N copies of the multicast to their antenna before throwing all of them but one away. Surely, this can be improved. Multi-unicast over radio broadcast has to be the least efficient mechanism to achieve this.

With so many wireless devices now, streaming live sports events over multicast should be ultra efficient but this isn't the case on 802.11.

There is work to be done in the IEEE and I think that the PIM and MBONED WGs would be pleased to see us open a dialog with IEEE to improve this deficiency.

Optimizing for a single link layer is a rathole that we should avoid if you can take a step back and look at things from a long term perspective. Coming up with an optimization or work-around for a single link layer is fine as a short term solution.

Tom

---

From: James Andrewartha <[email-masked]>
Date: Fri, 1 Aug 2014 11:54:59 +0800

Hi Tom,

> With most radios, multicast is the most efficient form of transmission. But in 802.11, every receiver in range currently receives N copies of the multicast to their antenna before throwing all of t…

I don't know how familiar you are with 802.11, but the core problem is
the methods used to increase the data rates to clients mean each client
can speak to the AP at a different rate. In short, multicast is
inefficient for 802.11 because it must speak at the slowest rate the AP
allows clients to connect to it at. This can be as low as 1Mbps if
802.11b clients are allowed to connect.

The multicast to unicast conversion you speak of is an optimisation
implemented by some vendors, and works because if there are say 5
clients connected at say 300Mbps, and one client at 12Mbps, they can all
receive the transmission in unicast faster than if it were sent out as
multicast at 1Mbps for all clients to receive. Another optimisation some
vendors implement is to broadcast/multicast at the minimum rate of the
connected clients, which in this case would allow transmission at 12Mbps.

Also note that multicast/broadcast traffic will only ever use one
spatial stream as that is the minimum required by 802.11n/ac, while some
clients suport two or three spatial streams for higher data rates. So
again multicast to unicast translation will result in more efficient
transmission.

802.11ac MU-MIMO will further complicate things, as it will allow higher
unicast data rates and simultaneous transmission of possibly different
data streams to different clients at the same time.

Thanks,

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