Last Call Review of draft-ietf-mboned-ieee802-mcast-problems-09
review-ietf-mboned-ieee802-mcast-problems-09-tsvart-lc-fairhurst-2019-10-02-00

Request Review of draft-ietf-mboned-ieee802-mcast-problems
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-10-14
Requested 2019-09-30
Authors Charles Perkins, Mike McBride, Dorothy Stanley, Warren Kumari, Juan-Carlos Zúñiga
Draft last updated 2019-10-02
Completed reviews Tsvart Last Call review of -09 by Gorry Fairhurst (diff)
Intdir Last Call review of -09 by Tatuya Jinmei (diff)
Rtgdir Last Call review of -09 by Tal Mizrahi (diff)
Secdir Last Call review of -09 by Kyle Rose (diff)
Genart Last Call review of -09 by Pete Resnick (diff)
Genart Telechat review of -11 by Pete Resnick
Opsdir Telechat review of -11 by Dan Romascanu
Tsvart Telechat review of -11 by Gorry Fairhurst
Assignment Reviewer Gorry Fairhurst
State Completed
Review review-ietf-mboned-ieee802-mcast-problems-09-tsvart-lc-fairhurst-2019-10-02
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/smtLN9tu7i8OpP8qUine0jNp2nY
Reviewed rev. 09 (document currently at 11)
Review result Ready with Issues
Review completed: 2019-10-02

Review
review-ietf-mboned-ieee802-mcast-problems-09-tsvart-lc-fairhurst-2019-10-02

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.




Overall:

This document has some problems. Mostly, it needs some editorial work to align with other RFCs (see below).

The text also needs to clearly identify IPv4 and IPv6 description (see below)

The scenario in which recommendations are provided is unclear. There are many cases where multicast is routinely used over wireless. For example, in the events/entertainment industry to transfer video to mixers or monitors; to control equipment, etc. There’s also a use case for connecting multicast routers together and one in which you deliver multicast to a home as a part of its broadband service.  These are subtly different, and I think some appropriate setting of context at the start and in the recommendations section would be helpful.

There seem to be some transport issues that need to be addressed (below), but it does not propose a new transport mechanism. The main issue is that this needs to ensure an appropriate view of network and transport-related multicast protocols.

While the observations and insight seem valuable and helpful to document in this informational RFC-to-be, the recommendations are a little “preliminary”, and are over-stated in the abstract. 

Section 1/Abstract

The abstract suggests that this is providing recommendations, and indeed there are some recommendations but a lot of the focus is on techniques being used and their trade-offs. That analysis could be useful, but the abstract really does not seem to reflect the content. The last para of introduction seems to have a more faithful tone.

Section 2

Please also define: BSS in the terminology section. 
It could be more complete to also define WLAN.

Section 3.1.1

This says:
     “Consequently, there can be a high
   packet error rate (PER) due to lack of retransmission, and because
   the sender never backs off.”

Transport Issue - This may be practically true in many cases, but the absence of congestion control in deployed multicast apps is a failure to implement methods - Multicast congestion control methods exist and have been specified in the RFC-series. I think this text needs to be clearer that this lack of CC is not a fundamental design issue for a multicast transport, but that the network needs to operate in the face of traffic that does not implement this.

Section 3.1.2

The following topic is not unknown in the transport area:

  “the Access Point has to use a much lower
   data rate at a power level high enough for even the farthest station
   to receive the packet, for example as briefly mentioned in [RFC5757].”

Transport Issue - I once called this the “crying baby” phenomena... in that if you listen for one baby crying in a room and focus on that, all your attention is diverted from other children you are trying to look after... 

or more simply from a transport perspective a design needs to have a way to isolate the worst-case (or under-performing) multicast receiver from the group at the transport layer and either eliminate the flow of traffic to it (perhaps resuming that flow using unicast if that is allowed) or simply blocking the traffic from/to the receiver. Without that the multicast solution is unable to scale to arbitrary topologies, or a small number of STs with poor signal thwart all the other people who may be perfectly happy otherwise.

Maybe a small extra text block would help?

Please cite the section in RFC 5757 please - rather than expecting the whole doc to be consumed.

Section 3.1.3

This section is titled “3.1.3.  High Interference” - but I think that’s not really the full intention, could this be better “Capacity and Impact on Interference” - or something?

- I think the section may speak of two topics, and that should be clarified. One is increased channel utlisation (which can hardly be called interference) and increased power causing an increase in the area of interference for users who do not use this AP.

Section 3.1.4 

Should the title be /Power-save Effects on Multicast/ or /Power-saving Effects of Multicast/?

Section 3.2.1

Is ARP using IPv4 Multicast? I am not aware of a multicast variant of ARP, it traditionally uses a broadcast service.

Is DHCP Multicast? Which spec?

The list for IPv4 does not include multicast control or routing protocols, such as IGMP and PIM...

Section 3.2.2

The IPv6 list of protocols does not include multicast routing protocols (e.g. PIM).

Section 3.2.3.  

This section talks about MLD issues, it seems to me that the same issues arise with IPv4 IGMPv3. I suggest you write a section on IGMPv3.

I don’t believe the following phrase is sufficient:

“Forwarding multicast frames into a Wi-Fi-enabled area can
   use such switch support for hardware forwarding state information.”

- IGMP or MLD are IP protocols, and for a switch to utilise this information it needs to implement snooping or proxy functions. There are IETF specifications on these subjects and they should be each cited:

e.g., RFC 4541, - Considerations for Internet Group Management or RFC4541 or both - you will know what is most relevant.

Please clarify:
  “ Some switch vendors do not support MLD,
   for link-scope multicast, due to the increase it can cause in state.”
- does that statement imply they drop or do they flood this traffic? which?

Section 3.2.4

Is the title correct - should it be something like “Spurious Neighbour Discovery and ARP Traffic”?

Section 3.2.4

This section has a title that reflects IPv6 use of MLD, but text that is IPv4-centric concerning ARP. I suspect there needs to be “IPv4” inserted in the first two paras. 
  “In the cases where the IP is assigned to a
   host, the router broadcasts an ARP request, gets back an ARP reply,”

Section 3.2.4

This contains this sentence: “Around 2,000 broadcasts per second have been observed at
   the IETF NOC during face-to-face meetings.”
- I am sure anyone who attends an IETF would understand, but this document has a wider audience and that sentence needs explained or generalised, because it does not fit at the end of this para at the moment.

<See note at the top about being more clear about scenarios being described>.

Section 4.6.1:

“   In many situations, it's a good choice to use unicast instead of
   multicast over the Wi-Fi link.  This avoids most of the problems
   specific to multicast over Wi-Fi, since the individual frames are
   then acknowledged and buffered for power save clients, in the way
   that unicast traffic normally operates.”

Transport Issue --- Well yes and no!

I think this is rather too bold advice, because I suspect it depends on the traffic and the deployment scenario. If the traffic is control or low volume, then I could be persuaded easily that this was good advice. If the desire is to stream to one or two endpoints at home - then hat’s probably cool advice.

If the traffic was streaming control data to 100’s of stations (e.g. in an application sending lighting-control to control equipment at a conference venue); or streaming multicast video to many monitors- that may not be the correct advice at all! 

This text will need a little more preface to identify the cases when this applies.

Section 4.6.2, 

Please refer to the IGMP and MLD snooping RFCs.

Section 5.2.1, 

Can you add a reference for “Gratuitous ARPs” - some people think it something, some think something else;-)

Section 5.2 (several)

In section 5.2 mention is made of ARP in several topics, but it was not clear whether the same methods would each apply to ND for IPv6 - if the WG knows this it would be good to say something, or say this is not known.

Transport Issue - The document makes no mention of DSCPs, or of prioritisation of traffic within IEEE 802 and mapping to ACs. That seems like a topic that needs at least to be cited, especially since there is discussion of control v. transport  competing for resources, RFC 8325 defines a mapping to User Priority and Access Category (the RFC has no mention of multicast). This topic may have been omitted on purpose, I’d be interested to know that was the case.

I’m curious as to whether the WG has considered RFC6636 in this analysis?