Re: [Mcast-wifi] [mboned] working group draft related to the topic of interest for this discussion group

Hi,

Thanks Charlie and Mike, I think this document is important and valuable and
I'm glad to see the progress.

I've read through the -01 version, and I have a few comments.

High-level general comments:

1. IETF's conference WLANs
I'll +1 Joel's comment that several places are strangely specific to the
wifi networks at IETF conferences.

Although some of the mentions have useful observations, I think it's
probably at best confusing to readers who haven't attended the conferences
in person when the context wasn't explained, like in section 5.1 under NAT
and Stateful firewalls.

Is there a good way to rephrase the explanations to refer to something like
a more generic "WLAN for a conference with ~3k STAs"?

And if the IETF is unusual in its commitment to the end-to-end principle in
practice (as I think is the case), I would say it's useful to talk about
pros and cons and common practice without apologizing for what IETF does at
its conferences, regardless of pitchforks.


2. Spelling and definition of "wifi"
I don't have a strong position here, but will this eventually get kicked
back to replace uses of "wifi" with "Wi-Fi" or "IEEE 802.11 WLAN" or
something?  If "wifi" is clear and uncontroversial, I have no objection to
it, I just wanted to call attention to it as a point that might get
objections at some point, and ask if it'll need changing?

Regardless, I'll suggest (maybe in the definitions section?) describing or
providing a reference to the set of specifications this document is
referencing with the term "wifi" (or "Wi-Fi", if that turns out to be the
preferred language).



Editorial:

1. (Abstract)
I think this sentence could be dropped entirely, it's sort of implicit in
having it eventually turn into an RFC:

                      IETF multicast experts have been
   meeting together to discuss these issues and provide IEEE updates.
   The mboned working group is chartered to receive regular reports on
   the current state of the deployment of multicast technology, create
   "practice and experience" documents that capture the experience of
   those who have deployed and are deploying various multicast
   technologies, and provide feedback to other relevant working groups.


2. (Abstract, nit)
chioces -> choices

3. (section 1, nit)
enhamcements -> enhancements

4. (section 1, nit)
"neighborhood discovery" -> "neighbor discovery" (I think?)

5. (section 1)
I think the list of environments with multicast video streaming should
include homes. This use case is becoming more common, I believe.

I'll offer some language here, but feel free to wordsmith to your own taste. I
Just would like to see home video services included:

OLD:
   more applications, such as push to talk in hospitals, video in
   enterprises and lectures in Universities, are streaming over wifi.
   Many types of end devices are increasingly using wifi for their
   connectivity.
NEW:
   more applications, such as push to talk in hospitals, or video in
   enterprises, universities, and homes, are sending multicast IP to end
   user devices, which are increasingly using wifi for their connectivity.

5.a. (section 1)

Is it worth adding here use cases that are considered probably useful, but
not currently done with multicast over wifi, in part because of these
concerns? (e.g. apps providing instant replays in a stadium IIUC currently
use unicast, but could theoretically share a lot of bandwidth)

6. (section 1, nit)
period ends sentence early.
OLD:
   issues created by multicast traffic.  as described in Section 5.
NEW (suggested):
   issues created by multicast traffic, as described in Section 5.


7. (section 1)
Is the 2nd to last paragraph intended to be part of the final document, or
as a note to contributors or something?

8. (section 2)
A few other terms might be appropriate here that I noticed later:

ACK - the 802.11 layer 2 acknowledgement
PER - packet error rate

9. (section 3 title, nit)
mulitcast -> multicast

10. (section 3.1.2)
I think one of the "wired" in the first sentence should be "wifi" or "wireless":
   ... multicast over wired versus multicast over
   wired is that...

11. (section 3.1.2, paragraph 2 nit)
"an Access Points" -> "an Access Point"

12. (section 3.1.2, paragraph 3)
I'm slightly confused by "lowest common denominator rate" -- I think that's
the slowest rate of all the connected devices, or the minimum configured
rate in the AP, is that correct?

Also, the different sentences seem to refer to this value both as the "basic
rate" and the "base data rate"; are those interchangeable, and are they
normative? Sorry, I haven't read all the relevant 802.11 specs, and I'm not
sure offhand if those have different meanings or not.  (A “as defined in
section XX of 802.YY” might be useful here, if that exists?)

13. (section 3.1.3)
I think the term "client" was not defined, but it looks like it's used
interchangeably with "STA", is that correct?  Should it be either defined or
changed to STA?  I'm not completely sure whether any technical distinction
is intended.

14. (section 3.2.1)
I think ARP is not an IPv4 protocol. Maybe "IPv4 protocols" -> "protocols
commonly used in IPv4 networks"?  (Also, I thought it uses broadcast but not
multicast--is there a common multicast case, or should this say "multicast
or broadcast"?)

15. (section 3.2.1)
I think UPnP might be a good inclusion here.

16. (section 3.2.1)
I think Bonjour is the same as mDNS, right?

Also: I'm a little uncomfortable with the Apple sentences here, though I
think the information is valuable. Maybe it could be moved and restated as a
mitigation for conference/enterprise networks? Something like removing the
Bonjour sentences here and adding something like this under section 5 (though I’m
not sure it fits with 5.1, maybe as part of a “5.2 Mitigating spurious discovery
messages” or something?):

"
suppress or block mDNS messages

    In networks that must support hundreds of STAs, operators have observed
    network degradation due to many devices simultaneously registering with
    mDNS (for example, with Apple's Bonjour service). In a network with many
    clients, it is recommended to ensure that mDNS packets designed to
    discover services in smaller home networks be constrained to avoid
    disrupting other traffic.
"

(In fact, I suspect this could be generalized further--what happens if a
UPnP service becomes popular on laptops or phones?)


17. (section 4)
Would it be useful to include a section for AMT? I think I could suggest
a couple of paragraphs if you think it would be a useful addition.

I think it's in the same category as DMS and multicast-to-unicast, and
perhaps the 3 should be grouped into a common section together, since they
share some characteristics that could share a description (and maybe a
note about applicability for home networks, and scaling considerations in
networks with many STAs subscribed to traffic).


I'm out of time for more detailed comments right now and I wanted to send
out what I've got, but please do not be surprised if I add some further
comments at some point unrelated to what I’ve got so far.

I'm looking forward to the next revision, I think this is a useful document,
and I'm glad to see it moving forward.

Thanks for working on it, and let me know if there's anything you'd like me
to clarify.

Kind regards,
Jake

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned