Reviewer: Gorry Fairhurst
Review result: Ready with Issues
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@xxxxxxxx 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?
