[MBONED] review of draft-perkins-intarea-multicast-ieee802-03 draft-mcbride-mboned-wifi-mcast-problem-statement-01

[joel jaeggli <[e-mail]>]

Greetings,

I have chosen to review both of these documents at this time as they
appear to me to be attempts to address the same problem space from the
vantage point of slightly different but overlapping communities
(evidenced by the authors) both of which have a vested interest in IP
multicast operation on ieee 802.xx wireless networks. This review is
seperated into the observations common to both followed by (limited)
commentary on each document.

While both documents address the challenges of arp / ND and aperiodic
multicast transmission,
draft-mcbride-mboned-wifi-mcast-problem-statement-01 has more focus on
application use of multicast above and beyond basic
subnet/adjacency/resource discovery applications.

draft-perkins-intarea-multicast-ieee802-03 takes a more technical and
nuanced look at the underlying 802.xx implementation of
multicast/broadcast packet transmission. It is oddly specific in some
areas to experiences gleaned from the IETF network, which while it may
be a product of our experience, is  by no means a unique environment,
and these challenges are to a great degree common or in fact worse  in
other wireless environments (where there might be more low powered
devices, less spectrum or radio coordination, a diversity of management
domains and so on.

it's  not clear to me from the outset what the audience for an
eventually published document might be.

	Advice to implementors?

	Feedback to the IEEE?

	Operational advice?

	Go from problem statment towards work on conclusions?

draft-perkins-intarea-multicast-ieee802-03  is the slightly more mature
document of the two,  I don't think that there is much justification for
advancing both given that they have fairly high overlap without being
complimentary, so I would encourage consolidation and coordination
between the int interests and those of the mbone/multicast community
towards something that is more than the union of the two.

>From my vantage-point the best outcome is one where the IETF provides
advice to vendors (becaue there are implementation specific tweaks and
optimation that can make many situations better) an the IEEE that
results in the employment of multicast being less disruptive and costly
and potentially to devices on wireless lans. work on ietf protocols
associated with arp/nd resource discovery to make them generally less
costly on the wire and more sensitive to power / cpu usage is a
desirable property as well pariticularly  of there are situations where
they can be avoided entirely (for example not having to defend addresses
via DAD because of something like
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13).


Some comments specific to each document

- draft-perkins-intarea-multicast-ieee802-03 -

   	3.1.2.  Lower Data Rate

   	this rate might be as low as 6 Mbps, when
   	some unicast links in the same cell can be operating at rates up to
   	600 Mbps.

In fact backward compatibility and  multi-stream implementations mean
that the maximum unicast rates are currently up to a few Gb/s so there
can be a more than 3 order of magnitude difference in the transmission
rate from the basic rates to optimal unicast forwarding. some techinues
employed to increase spectral efficiency such a spatial multiplexing in
mimo systems are literally unavailable with more then one intended
reciever so it's not simply the case that nominal transmission rates
available are limited by backwards compatibility.

	3.2.2. IPv6 issues

Respecting some of the cost of multicast on wireless networks these are
not strictly wireless problems reductions in the amount of signaling
required is better for the control-planes of routers, and for all hosts
ultimately, whether that is unicast RAs, prefix per host, or simply rate
limits on layer 2 learning e.g. https://tools.ietf.org/html/rfc6583
problems. 3.2.4 and 3.2.2 therefore are very much problems that extend
beyond the wireless domain.

Specifically with 3.2.4 the arp problem also applies to ND, in both
cases non-standard counter-measures (arp sponging unlearned entries as
in 5.1 for v4) various forms of off-net vs on-net driven ND suppression.

	On a wired network, there is not a huge difference amongst unicast,
	multicast and broadcast traffic;

Inadvertent flooded traffic or high amounts of ethernet multicast on
wired networks can be quite a bit less costly due to nic filtering, then
in cases where devices have to wake up effectively to process packets.
also the fact that these networks tend to be switched futher reduces
impact (there is effectively no collision / scheduling problem until you
get to extremely high port utilization)

	4.3

not clear how this directly impacts multicast / except that a unicast
optimization ight seperately send to different STAs at different times.
optimization around long DTIM intervals to allow clients to sleep longer
clearly has impacts on performance, convergence time and how uch needs
to be sent which the device wakes up.

	4.6

	DMS is not currently implemented in products.

work on and review of DMS
http://ieeexplore.ieee.org/document/7969670/?reload=true
http://eprints.networks.imdea.org/524/1/video_v01.pdf

	5.1

barely deals with ipv6, even though the problems are essntially the same.


- draft-mcbride-mboned-wifi-mcast-problem-statement-01 -

	1.

	And many end devices are increasingly using
	wifi for their connectivity.

it's not really that this is a new and increasing alternative to wired
connectivity. there's no serious or common alternative to wirless 802.x
network usage.

 	One of the primary problems multicast
   	over wifi faces is that link local 802.11 doesn't necessarily support
   	multicast, it supports broadcast.

This is a possibly necessarily simplification, there are not naturally
great mechanisms within a common collision domain to limit reciever
membership so even the ability to limit membersship to recievers that
are part of the reciept naturally makes the air interface unavailable
for a time.

	4.
   	Apple's Bonjour protocol, for instance, provides service discovery
   	(for printing)

mdns service discovery covers a great deal of (and increasing number) of
diverse services. most of them are more or less invisible to users, e.g.
they're not aware that they re using a service discovering mechanism, or
that autonomous deivces are using them irespective of user input.