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. After the transport review was submitted, two revisions of the draft were published, but did not address the general tone of the document or the request for more detailed explanation on the topics. This is therefore an updated review after revision 11, and a revised recommendation to improve the document before publication. It replaces the former review. Overall: This document has some problems. Mostly, it needs some editorial work to align with other RFCs (see below), but it also needs to address various transport topics. The text also needs to clearly identify IPv4 and IPv6 description (see below). There meeds to be much more clarity with respect to the differences between IPv4 and IPv6 - and recommendations do need to be provided for each. 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 are 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 “preliminary”, and are over-stated in the abstract. This is misleading, and has not been clarified yet in revision 11. 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 the introduction seems to have a more faithful tone. I suggest the editors consider updating the other text to adopt this style, and perhaps focus more on the 802-related scope in the way the document is introduced. TEXT: “This means that routers very often receive packets destined for IPv4 addresses regardless of whether IP addresses are in use. “ - Why just IPv4? The text throughout needs to clearly identify IPv4 and IPv6 description. There needs to be much more clarity with respect to the differences between the ways IPv4 and IPv6 operate and the implications on lower layers - and recommendations do need to be provided for each. TEXT: “Multicast allows sending” This sentence could be improved - the key point being that multiple receivers can receive the same data from only one transmit operation. Section 2 Please also define: BSS in the terminology section. It could be more complete to also define WLAN. Section 3.1.1 This section says: “Consequently, there can be a high packet error rate (PER) due to lack of retransmission, and because the sender never backs off.” This speaks of packet error rate. This term could mean undetected error rate (or ratio) or its could refer to loss. The next sentence uses the term “loss”, which could mean the first uses refers to residual errors, or could be use of inconsistent language - either way, it would seem more useful to speak of the loss ratio for the IP layer. Transport Issues I think this text needs to be much 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. - A “lack of retransmission” may be practically true in many cases with respect to applications using transports over multicast, but has been specified in various RFCs. Multicast congestion control methods exist and have been specified in the RFC-series. - The absence of congestion control in deployed multicast apps is a failure to implement methods, the IETF guidance is clear (e.g. see UDP Guidelines BCP - RFC 8085). Section 3.1.2 “ the least reliable receiver.” - I think this is actually the receiver that experiences the poorest channel, the current text suggests there could be something wrong with a receiver, but that is only one part of the problem. 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. A small extra text block would help clarify these issues. Please also cite the section in RFC 5757 - rather than expecting the whole doc to be consumed. The document is rather long and some indication of which section or sections apply would be of great help top the reader. 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 the other is increased power causing an increase in the area of interference for users who do not use the same 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. . Section 4.4: - This section has title has a different capitalisation to other sections. Although it refers to a reference for more details, the current text is not clear what impact this has on control traffic or multicast transports. Please explain what “down out” means. Section 4.5: TEXT: “Every IPv6 node subscribes to a special multicast address for this purpose.” - Since this is not a single address, it would be helpful to explain how the addresses are used by ND/SEND. TEXT: “NDP may be used to request additional information “ - poorly formed sentence, pleases rephrase. 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 the current text 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 4.7.1 TEXT: “GCR (defined in [dot11aa]) provides greater reliability by using either unsolicited retries or a block acknowledgement mechanism.” - I thinks this is a layer 2 mechanism. and that really should be made clear, and some discussion is then needed about this relates to multicast transports - and whether doing reliability at two layers is a good or poor design choice - so that people understand the tradeoffs here. The present text appears quite misleading, only referring to the impact on latency. Section 5.1 “5.1. Mitigating Problems from Spurious Neighbor Discovery” - Seems like it would be IPv6 centric from the title (mentioning ND) although actually it is far too Ipv4-centric, not mentioning ND/SEND in the text. Both of these issues need to be fixed. Section 5.2.1, Can you add a reference for “Gratuitous ARPs” - some people think it something, some think something else;-). Please explain. Section 5.2 (several places) 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. This should be added. TEXT: “designed to discover services in smaller home networks be constrained to avoid disrupting other traffic.” - How is this to be achieved, please explain the scoping to be used. 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, but at least a summary should be provided. I’m curious as to whether the WG has considered RFC6636 in this analysis?