Re: [Int-area] review of draft-perkins-intarea-multicast-ieee802-03 draft-mcbride-mboned-wifi-mcast-problem-statement-01

[Charlie Perkins <[e-mail]>]

Hello Joel,

The [mboned] WG has adopted draft-ietf-mboned-ieee802-mcast-problems.  I 
have just posted an update that includes the relevant material from the 
earlier [intarea] individual submission, 
draft-perkins-intarea-multicast-ieee802, which you also reviewed. I have 
some follow-up to your review comments below.


On 11/14/2017 6:36 PM, joel jaeggli wrote:
> 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.

The contents of that draft were pretty much contributed text from the 
co-authors, and there were a number of empty holes for future work.  But 
the future work kept not getting done.

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

Yes.

>
> 	Feedback to the IEEE?

Not specifically, but the IEEE folks would definitely notice any work 
that we do.

>
> 	Operational advice?

Yes.

>
> 	Go from problem statment towards work on conclusions?

I am not sure about this.  For now I would put it as a lower priority, 
except insofar as bits of advice to implementers and operators would 
count as 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.

Check.

>
> >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).

I very much agree with this.

>
>
> 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.

We could incorporate a version of your text into section 3.1.2 of the 
new revision.

> 	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.


Do you think that the draft should avoid mention of problems that are 
not specific only to multicast, or should we mention them anyway along 
with the observation that they also extend beyond the wireless domain?

>
> 	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)

We could incorporate your text into this discussion as well.

>
> 	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.

It possibly deserves specific mention because multicast affects every 
STA and sometimes is transmitted periodically.  I guess this also falls 
into the category of problems that are not specific only to multicast, 
but which exact a particularly heavy penalty on multicast.  We should 
also say this (which I just found from a wireless-net tutorial) :

    When any single wireless client associated with an access point has
    /802.11/ power-save mode enabled, the access point buffers all
    /multicast frames/ and sends them only after the next DTIM (Delivery
    Traffic Indication Message) beacon.


> 	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

Thanks for the citations.

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

Good point.  This will require a good bit of textual revision to be 
applicable to IPv6.

>
>
> - 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.

How about:

         Many end devices do not have any serious or common alternative
	to wireless 802.x for their connectivity.



>
>   	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.

I think that sentence needs to be significantly reworded.  Any suggested 
text will be appreciated.

>
> 	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.

Your text might form a useful prologue for the sentence about Bonjour.

Regards,
Charlie P.