Re: [Mcast-wifi] [mboned] working group draft related to the topic of interest for this discussion group
Donald Eastlake <d3e3e3@gmail.com> Sat, 11 August 2018 20:54 UTC
Return-Path: <d3e3e3@gmail.com>
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 19C7E130EAE; Sat, 11 Aug 2018 13:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gIQ6h3SvziWV; Sat, 11 Aug 2018 13:54:47 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1421130EA9; Sat, 11 Aug 2018 13:54:46 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id j81-v6so7482626ite.0; Sat, 11 Aug 2018 13:54:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UaeH7Bq+pAYhh5D8Nyeyds6C3RSXz3iDQLJyRhI/FU8=; b=TmZlRf8MYOusJzAOJtwlu1FHQgmjm8kax5QC98GDoLfR1tOsLwDvolVlazHMRqA0fG quHa9mUveDMR70cOsuIhHgaJU+U9xWm6keRD4kf4YxezxO6fvtQPn12iWS8cLPFEhQRk H0quvOarNz/2FKJBM+RJ+LhH34Jkhon+dcifiVVLp9x1KXKlJ0ZNWY2+i/i4pTnt49is IsbRakVwyPFSj49JT3gBQH0gbv6vxu1ZuLQMXFAvGFCELEei9H/E/l/Ej7gZr9qXKjBi zhe8x2ORDpuZ/koORLH8ds+xbJNEHT+M710+k3EMJZOpKOHopBFrkVendgeCXpjDCM4w xRoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UaeH7Bq+pAYhh5D8Nyeyds6C3RSXz3iDQLJyRhI/FU8=; b=IwSVjXG0A7OCupkE1m8uhaKVdEdMdiELCuIXQ0bsJBvwJkjuO1PHFJqjYcdO3DijN5 fb6Sdths3FndmFH9dHEkfWLfLJCYWm7D9oQxzGhGS4ZVT4qUlXxszaktopzD0iMDB3kD vCURRxjptVSkIVmJLZIdKK9N+Ks0XHshRA0Vw+VyCUY5n31aqoDm9v4jl8ZNRVhr0xsx fSCFoKKMSB2fQ9q6mRlzukvDjDak2vpK9SP5cSZvtrdGDH26XXznKzVxrFpZimXpfzlU Z6q9+3e8tAppz9mPsX58AqdXEgikpXRWiuQiVNh5+BE0pTVVzAMGyhVlo6NsJvjlv5f0 ndmg==
X-Gm-Message-State: AOUpUlEAcWKSOPlmIPrshELY1LJC5KIZcR2Xes5+GEzahDjAh4dsrAXu vwwVG5wj8an7F2Umsh2sgODsZ/LBfK6z4uYIn81NZw==
X-Google-Smtp-Source: AA+uWPyHzpBKvwOw6hjn5LMKcqDUlWEkCmEymWkAssvasQt98q542gA8+fX9Ta6zE3CQk7dHugP98FNiLF92FmLP1FY=
X-Received: by 2002:a02:4502:: with SMTP id y2-v6mr10615466jaa.11.1534020886072; Sat, 11 Aug 2018 13:54:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a6b:4d0:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 13:54:30 -0700 (PDT)
In-Reply-To: <711DCC66-CB01-479D-A3DF-587BA4A76E27@akamai.com>
References: <cbccbbef-c518-7884-13c4-f324e646cd8f@earthlink.net> <09210197-91cc-7b5a-36f0-7318557b225a@earthlink.net> <711DCC66-CB01-479D-A3DF-587BA4A76E27@akamai.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 11 Aug 2018 16:54:30 -0400
Message-ID: <CAF4+nEFOze80eup2OFqTsFwz+XoxYf67ro7NoAqUZ3C3xmEyBg@mail.gmail.com>
To: "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>
Cc: Charlie Perkins <charles.perkins@earthlink.net>, "mcast-wifi@ietf.org" <mcast-wifi@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/xKtlvSHntzq6spcC5TLT6yM_P_U>
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.27
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: Sat, 11 Aug 2018 20:54:49 -0000
I strongly recommend using the hyphenated for of wi-fi (or Wi-Fi). That is the most accepted form. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Fri, Aug 10, 2018 at 9:29 PM, Holland, Jake <jholland=40akamai.com@dmarc.ietf.org> 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 >
- [Mcast-wifi] Submission of new draft Charlie Perkins
- [Mcast-wifi] [mboned] working group draft related… Charlie Perkins
- Re: [Mcast-wifi] [mboned] working group draft rel… Holland, Jake
- Re: [Mcast-wifi] [mboned] working group draft rel… Donald Eastlake
- Re: [Mcast-wifi] [MBONED] [mboned] working group … Manfredi (US), Albert E
- Re: [Mcast-wifi] [mboned] working group draft rel… Charlie Perkins