[Tsv-art] Tsvart telechat review of draft-ietf-mboned-ieee802-mcast-problems-11

[Gorry Fairhurst via Datatracker <[e-mail]>]

Reviewer: Gorry Fairhurst
Review result: Almost Ready

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
[e-mail] 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.

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

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?