[MBONED] Benjamin Kaduk's Discuss on draft-ietf-mboned-ieee802-mcast-problems-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mboned-ieee802-mcast-problems-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-ieee802-mcast-problems/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 9 says that "[RFC4601], for instance, mandates the use of IPsec
to ensure authentication of the link-local messages in the Protocol
Independent Multicast - Sparse Mode (PIM-SM) routing protocol" but I
could not find where such use of IPsec was mandated.  (I do recognize
that a similar statement appears almost verbatim in RFC 5796, but RFC
5796 seems focused on extending PIM-SM to support ESP in additon to the
AH usage that was the main focus of the RFC 4601 descriptions, and does
not help clarify the RFC 4601 requirements for me.)  The closest I found
was in Section 6.3.1 of RFC 4601: "The network administrator defines an
SA and SPI that are to be used to authenticate all link-local PIM
protocol messages (Hello, Join/Prune, and Assert) on each link in a PIM
domain" but I do not think that applies to all usage of PIM-SM.  Am I
missing something obvious?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

To what extent would it be wrong to use the common "BUM" abbreviation
("Broadcast/Unknown-Unicast/Multicast" to discuss the classes of traffic
discussed in this hdocument?  That is, we say "multicast" a lot but in
several places the discussion suggests that broadcast is treated
similarly, and it would be nice to have a uniform treatment for the
cases where broadcast and multicast are effectively equivalent, so that
it's easier to call out when there is an actual distinction between the
handling for the two.  (I guess that the "unknown unicast" case doesn't
really apply at the MAC layer...)

I have very little background on IEEE radio technologies, or radio
technologies in general; my apologies in advance for the many questions
I ask that betray my ignorance.  I understand that I'm not exactly the
target audience for this document and that it's not going to be
appropriate to add clarifying text at all locations where I ask for help
understanding the content.

Abstract

   This document describes the problems of known limitations with
   wireless (primarily 802.11) Layer-2 multicast.  Also described are

nit: this doesn't flow very well; maybe just "describes the known limitations
of wireless" would suffice?

Section 1

   send duplicate data to each recipient.  With broadcast traffic, data
   is sent to every device regardless of their interest in the data.

nit: maybe "expressed interest"?  I expect there are some
infrastructure-type broadcast traffic that is of interest to all
participants in many IP networks.

   problem.  Wi-Fi traffic classes may help.  This document is intended
   to help make the determination about what problems should be solved
   by the IETF and what problems should be solved by the IEEE (see
   Section 8).

Do we need formal IEEE buy-in before making this kind of statement?

   rates, no acknowledgements, and low data rate.  It also explains some
   enhancements that have been designed at the IETF and IEEE 802.11 to
   ameliorate the effects of multicast traffic.  Recommendations are

I suggest clarifying whether this is "ameliorate the effects of
multicast traffic on other users of the spectrum" or "ameliorate the
effects of the radio medium on multicast traffic".

Section 2

I agree with the TSV-art reviewer that a more precise definition of what
the "packet error rate" is measuring would be useful.

Section 3.1.1

   traffic.  Since multicast makes point-to-multipoint communications,
   multiple acknowledgements would be needed to guarantee reception at
   all recipients.  Since there are no ACKs for multicast packets, it is

nit: there seems to be an implicit "but that would be highly inefficient
and is not done" between "multiple acks would be needed" and "there are
no acks".

Section 3.1.2

   Multicast over wired differs from multicast over wireless because
   transmission over wired links often occurs at a fixed rate.  Wi-Fi,
   on the other hand, has a transmission rate that varies depending upon
   the STA's proximity to the AP.  The throughput of video flows, and
   the capacity of the broader Wi-Fi network, will change and will
   impact the ability for QoS solutions to effectively reserve bandwidth
   and provide admission control.

nit: rhetorically, this sentence doesn't say when/why the throughput
will change, but rather treats it as a spontaneous and independent
event.

   For wireless stations associated with an Access Point, the power

nit: I assume "associated with" refers to the current radio traffic, and
not some administrative or organizational grouping, as a naive reader
might expect using the default meaning of "associated"; some additional
lead-in might be helpful.

   In fact, backward compatibility and multi-stream implementations mean
   that the maximum unicast rates are currently up to a few Gbps, so
   there can be more than 3 orders of magnitude difference in the
   transmission rate between multicast / broadcast versus optimal
   unicast forwarding.  Some techiques employed to increase spectral

nit: I think "backward compatibility" is only applicable to the 3 orders
of magnitude difference in tx rate, and is not applicable to the maximum
unicast rates being a few Gbps.

Section 3.1.3

   communications and degrade the overall capacity.  Furthermore,
   transmission at higher power, as is required to reach all multicast
   STAs associated to the AP, proportionately increases the area of
   interference.

nit: it's most precise when talking about interference to say what
interferes with what else; in this case it would be (IIUC) the area in
which multicast traffic causes interference with other consumers of the
radio spectrum.

Section 3.1.4

   One of the characteristics of multicast transmission is that every
   station has to be configured to wake up to receive the multicast,
   even though the received packet may ultimately be discarded.  This

This seems like something of a non sequitur -- the text would work if we
were discussing broadcast traffic, but for multicast aren't the intended
recipients known?

   o  Both unicast and multicast traffic can be delayed by power-saving
      mechanisms.

Just to check my understanding: this is "works poorly" just because of
the additional latency?  (Is this effect more pronounced for multicast
than for unicast?)

   o  A unicast packet is delayed until an STA wakes up and requests it.
      Unicast traffic may also be delayed to improve power save,
      efficiency and increase probability of aggregation.
   o  Multicast traffic is delayed in a wireless network if any of the
      STAs in that network are power savers.  All STAs associated to the
      AP have to be awake at a known time to receive multicast traffic.

These kind-of feel like sub-bullets of the previous point.

Section 3.2.1

   o  ARP
   o  DHCP
   o  mDNS [RFC6762]
   o  uPnP [RFC6970]

   After initial configuration, ARP (described in more detail later) and
   DHCP occur much less commonly, but service discovery can occur at any
   time.  Some widely-deployed service discovery protocols (e.g., for
   finding a printer) utilize mDNS (i.e., multicast).  It's often the

nit: doesn't uPnP also fall under the "service discovery protocol"
mantle?  It's a little weird rhetorically to only mention the one but
not the other, and leaves the uninformed reader wondering what the story
is about uPnP.

   first service that operators drop.  Even if multicast snooping is

nit: rhetorically, this is missing some causality for "first of what".

Section 3.2.3

On the whole this section is hard for me to follow.  I make a couple
specific points, but a broader rewrite may be in order.

   Multicast Listener Discovery (MLD) [RFC4541] is used to identify
   members of a multicast group that are connected to the ports of a
   switch.  Forwarding multicast frames into a Wi-Fi-enabled area can
   use such switch support for hardware forwarding state information.

Er, what switch support -- where did we previously discuss this?

   However, since IPv6 makes heavy use of multicast, each STA with an
   IPv6 address will require state on the switch for several and
   possibly many multicast solicited-node addresses.  Multicast

Am I supposed to know what a "solicited-node address" is based on the
references already provided?

Section 4.1

Is there an actual specification for Proxy ARP that can be referenced in
addition to the powerpoint deck?  I note that the toplevel Section 4
describes this content as "has been specified", which would seem to
exclude speculative proposals.

   The AP knows the MAC address and IP address for all associated STAs.
   In this way, the AP acts as the central "manager" for all the 802.11
   STAs in its basic service set (BSS).  Proxy ARP is easy to implement
   at the AP, and offers the following advantages:

Does it make sense to lead in this passage with "In Proxy Arp,"?

Section 4.3

I'm not sure how accessible this content will be to readers that do not
already have some background knowledge on wifi operation -- there are
some logical connections between sentences that are left fairly
implicit.

Section 5.1

         Some routers (often those based on Linux) implement a "negative
         ARP cache" daemon.  Simply put, if the router does not see a
         reply to an ARP it can be configured to cache this information
         for some interval.  Unfortunately, the core routers in use
         often do not support this.  When a host connects to a network
         and gets an IP address, it will ARP for its default gateway
         (the router).  The router will update its cache with the IP to
         host MAC mapping learned from the request (passive ARP
         learning).

nit: the transition between first three and last two sentences seems a
bit lacking.

   Firewall unused space

         The distribution of users on wireless networks / subnets
         changes from one IETF meeting to the next (e.g SSIDs are
         renamed, some SSIDs lose favor, etc).  This makes utilization
         for particular SSIDs difficult to predict ahead of time, but
         usage can be monitored as attendees use the different networks.

nit: I don't think the reference to the IETF meeting network adds any
value here; the operational practice can be equally well described
without such reference.

   NAT

         The broadcasts are overwhelmingly being caused by outside
         scanning / backscatter traffic.  To NAT the entire (or a large
         portion) of the attendee networks would eliminate NAT
         translation entries for unused addresses, and so the router
         would never ARP for them.  However, there are many reasons to
         avoid using NAT in such a blanket fashion.

"attendee networks" seems to be another (implicit) reference to IETF
meeting networks; I suggest rewording.

   Stateful firewalls

         Another obvious solution would be to put a stateful firewall
         between the wireless network and the Internet.  This firewall
         would block incoming traffic not associated with an outbound
         request.  But this conflicts with the need and desire of the
         IETF and other organizations to have the network as open as
         possible and to honor the end-to-end principle.  An attendee on
         the meeting network should be an Internet host, and should be
         able to receive unsolicited requests.  Unfortunately, keeping

Again, a focus on the (IETF) meeting network that is not justified by
the scope presented in the Abstract and Introduction.

Section 5.2

Is there more that could be said about how this constraining is to be
done?  Are there well-known techniques to "segment off" (pun intended)
small areas of service-discovery traffic within a larger multicast
domain, that fall short of just blocking mDNS entirely?

(Also, why is this section indented at the level of the sub-topics of
the previous section, instead of normal section-level indentation?)

Section 7

   Future protocol documents utilizing multicast signaling should be
   carefully scrutinized if the protocol is likely to be used over
   wireless media.

It's not entirely clear that this advice is going to make it to the
authors of such future protocol documents, given the current intended
status of this document.  I might consider rephrasing in terms of the
potential consequences if such future protocols do not take into account
the considerations for wireless media, though that would of course make
the statement fit less well into a section entitled "Recommendations".

   Proxy methods should be encouraged to conserve network bandwidth and
   power utilization by low-power devices.  The device can use a unicast

nit: I think this should be something like "The use of proxy methods
should be encouraged"; right now the text has to be parsed as having
"proxy methods" as the subject that is getting encouraged to conserve
resources.  Alternately, just add a comma.

   Multicast signaling for wireless devices should be done in a way
   compatible with low duty-cycle operation.

Is there any further guidance to give on how this is to be done?  Do any
previous sections of this document offer specific advice that is
relevant to this point?

Section 8

   The IETF should determine guidelines by which it may be decided that
   multicast packets are to be sent wired.  For example, 802.1ak works
   on ethernet and Wi-Fi.  802.1ak has been pulled into 802.1Q as of
   802.1Q-2011.  If a generic solution is not found, guidelines for
   multicast over Wi-Fi should be established.

I don't understand how these sentences are related to each other.  The
first one seems to be suggesting that the IETF should be telling
protocols that use IP multicast that those protocols need to
differentiate their behavior based on the physical layer in use, which
seems (AFAIK) antithetical to the idea of the Internet Protocol.  The
second and third sentences seem to be making statements about particular
IEEE technologies, I guess saying that they are available for both wired
and wireless use, but doesn't tell me much about what features the IETF
might be using from those technologies or why I should care about them.
The last sentence talks of a "generic solution", but I don't know what
problem it's supposed to be a solution for and how it relates to the
previously mentioned technologies.

   There is no need to support 2^24 groups to get solicited node
   multicast working: it is possible to simply select a number of
   trailing bits that make sense for a given network size to limit the
   number of unwanted deliveries to reasonable levels.  IEEE 802.1,

What are "trailing bits"?

   issues.  In reality, Wi-Fi provides a broadcast service, not a
   multicast service.  On the physical medium, all frames are broadcast
   except in very unusual cases in which special beamforming
   transmitters are used.  Unicast offers the advantage of being much

This observation seems like it would be very useful to have much earlier
in the document.

Section 9

It might be worth mentioning the common issue with security protocols
for multicast or group communications where there's a tradeoff between
(expensive) per-message asymmetric cryptography and (cheap) symmetric
cryptography where the shared group key allows any group member to
impersonate the expected sender.

We also discuss several mechanisms for improving efficiency that in
effect involve a proxy acting on behalf of wireless stations (whether in
the AP or a separate entity); such proxy methods in general have
security considerations that require the proxy to be trusted to not
misbehave.

Similarly, when using mechanisms that convert multicast traffic to
unicast traffic for traversing radio links, the AP (or other entity) is
forced to explicitly track which subscribers care about what multicast
traffic.  This is generally a reasonable tradeoff, but does result in
another entity that is tracking what entities subscribe to which
multicast traffic.  While such information is already (by necessity)
tracked elsewhere, this does present an expansion of the attack surface
for that potentially privacy-sensitive information.

There are probably some privacy considerations worth mentioning for the
"backbone router" model discussed in Section 4.2.

   Multicast is made more secure in a variety of ways.  [RFC4601], for

Would it be accurate to rephrase this more like "There are a variety of
security mechanisms defined for multicast control- and data-plane
traffic"?  The current formulation feels confusing to me on two axes:
whether it describes current or future specifications, and the nature of
security improvements provided.  (Actually, are the listed mechanisms
only really applicable to control-plane traffic but not data-plane?)