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

Charlie Perkins <charles.perkins@earthlink.net> Tue, 06 November 2018 06:45 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: mcast-wifi@ietfa.amsl.com
Delivered-To: mcast-wifi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4581128CF2 for <mcast-wifi@ietfa.amsl.com>; Mon, 5 Nov 2018 22:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAOjlo_C9TZf for <mcast-wifi@ietfa.amsl.com>; Mon, 5 Nov 2018 22:45:46 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A042C128CB7 for <mcast-wifi@ietf.org>; Mon, 5 Nov 2018 22:45:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1541486746; bh=fUdSLgr4pSWvA5dt1/Gko41J3y6ykPn1XqTW ohK77Wo=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=ZrXdQ2ZOS7iMYFX/UfakjcrhYxOElzDfC OpuOfoTL7xiRquG4fMWYTcR4JYTNJtbCl3ArqMJqDhxGLvjsI8zDAIeRECtVLcZWsl2 JSfR4ylUhKB44qtpwRx3ZBqKDCJCF2y4t768kRR6woKq+XCu+UesfxL6GBcmZZsHmCk XcDECkwo/yISiclN76eKN/Dnolojobp3fojshDHh02RRwA+PGxfo/jqVDmfTk/s6HuJ T33ovCN9RJWgbQuyd7Arq8oX5JZ5DbxBr6Z+9WI0Z6FY1T6ekUcHqP0wGSwsaeBTB9r nUFqibvmrSjKATTt2IPgV0SMZ6NoOVOpU7s+y1UfQ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=ebrcy0SQGxAaVaUMkjdIg3ylGH2slOHbybCPrLE81v+3vubNFuggQRj+uvduMozAvGK+hb6wtLH8FWnzDKk3EXzuffWaJJ80nSEGVIeNDnAHPv8IgSSUhhgm5onhNz3ZXJS2D4BSi8BcA4vjCcP1uCx1+vBW2gnzVfYKG6krR+QeGIkY8YSptZfup1tOznEHmOaKOUBLJkSdCzNvmWl5UWffQqoatX3N9xN8pQvD+zNgIYmucjWA+UoFc2K/lmwm06bkDRLFG2gxvnianDsxaBCR2WB82MG7F9KkXM5SVQ9g73t/9ZifeIYI+a5yZP6BzDW9BnPudG03ATgDVxX55w==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [31.133.189.92] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1gJv7P-0007Nw-Mm; Tue, 06 Nov 2018 01:45:44 -0500
To: "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>
References: <cbccbbef-c518-7884-13c4-f324e646cd8f@earthlink.net> <09210197-91cc-7b5a-36f0-7318557b225a@earthlink.net> <711DCC66-CB01-479D-A3DF-587BA4A76E27@akamai.com>
Cc: "mcast-wifi@ietf.org" <mcast-wifi@ietf.org>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <a6ff06b1-ea2f-8e7b-6f04-542e2cae1f10@earthlink.net>
Date: Mon, 05 Nov 2018 22:45:40 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <711DCC66-CB01-479D-A3DF-587BA4A76E27@akamai.com>
Content-Type: multipart/alternative; boundary="------------16682446913E72B1AEB2714C"
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95978a9f480ea29d995f1d0cb97bb0e7cc350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 31.133.189.92
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/0CUU2RMMLLNyASxD-9hfLm90DjE>
Subject: Re: [Mcast-wifi] [mboned] working group draft related to the topic of interest for this discussion group
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <mcast-wifi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mcast-wifi/>
List-Post: <mailto:mcast-wifi@ietf.org>
List-Help: <mailto:mcast-wifi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 06:45:50 -0000

Hello Jake,

I am just now getting to your comments.  They are really much 
appreciated.  I hope to be able to discuss them during today's [mboned] 
session, but it is likely that my effort to include them in today's 
presentation has come too late.

No matter what, I will follow-up on the mailing list within the week. A 
new revision of the document will follow soon afterward.

Regards,
Charlie P.


On 8/10/2018 6:29 PM, Holland, Jake wrote:
>
> 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
>
>
> _______________________________________________
> Mcast-wifi mailing list
> Mcast-wifi@ietf.org
> https://www.ietf.org/mailman/listinfo/mcast-wifi