Re: AMT text requested

"Holland, Jake" <[email protected]> Tue, 2 Apr 2019 19:34:31 +0000

Newsgroups	gmane.ietf.mboned
Message-ID	<[email protected]>

Hi Charlie,

One more comment amending my original text:

In light of the recent points David raised about existing proprietary
solutions, I think we can incorporate those observations by just adding
a sentence to the end of the text I offered for 4.5.2, something like:

"
In some implementations, the AP uses the count of receivers for a
group to conditionally use multicast or unicast for that group,
depending on the amount of airtime each option would consume.
"

Also, the [ref] bit in that section could either be dropped or could
be pointed in some form to the linux kernel code, I think. There were
a couple of breadcrumbs someone sent me to find the right spot and
figure out how to reference it (or maybe David has a better suggestion
at a useful point to reference?):
https://lore.kernel.org/patchwork/patch/752538/
https://gitlab.labs.nic.cz/turris/openwrt/commit/f0c747dee5f0175a5f57ab232eebcf311429c788

HTH,
Jake

On 2019-04-02, 11:35, "Holland, Jake" <[email protected]> wrote:

Hi Charlie,

I'm following up on the comments at the mic for the Wi-Fi problems
draft. I wanted to clarify on-list, since it was discussed in the
meeting, so I've replied on this thread to my original response,
which was a follow-up to my earlier comments on-list:
https://mailarchive.ietf.org/arch/msg/mboned/OQqfmlGAprsCtBK3SS0ChGn-5Ik

In this follow-up, where I said I'll withdraw my suggestion (in the
"regarding section 5" bit), I was referring to my earlier comments
labeled section 5.a., from the first email:

<original>
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)
</original>

This comment is the one I withdraw, having tried and failed to think of some
good text to address it.

The rest of this follow-up (under the "paragraphs for AMT"), I
still think would make a good addition to the document. If you
disagree, please do discuss and comment, but I was trying to offer
some useful text that could go into the next rev of the document.

I do think the current section 4.5 is probably too thin and should be
expanded somehow. If you don't like this text, I'll at least still ask
that this be improved upon:

https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-04#section-4.5
<current-text>
4.5. Conversion of multicast to unicast

It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually.
</current-text>

Best,
Jake

On 2018-11-12, 22:42, "Holland, Jake" <[email protected]> wrote:

Hi Charlie,

Regarding section 5:
I couldn't think of what to add that makes sense here, so I guess I'll withdraw my suggestion.

I'm not sure whether it's because I don't know enough, since I've never tried to deploy one of these networks, or whether it's because nothing quite fits here.

(On further examination, I think the stadium video doesn't quite fit as something that's enabled by these mitigations, so I'll specifically withdraw that note. What I was looking for is a good, simple, example motivation for where these mitigations would be helpful, as a 2nd paragraph in the intro, but on reflection, I guess the reference to the issues in Section 3 is probably enough.)

Regarding the paragraphs for AMT:
Here's a rough attempt at the way I'd replace sections 4.5 and 4.6 (Multicast to Unicast, and DMS) with a single "multicast to unicast" section that includes layer 2 multicast-to-unicast, DMS, and AMT as subsections that all achieve basically that same thing.

Again, please feel free to use your judgement and take whatever you like from this, and remove or change whatever you don't like. If you prefer to simply adapt the AMT paragraph into a 4.7 section, I'm fine with that and won't hold an objection open, but I'll humbly suggest that an approach like this seems better to me, so I thought I'd send it this way in case you agree:

"
4.5. Using Unicast Instead of Multicast

4.5.1. Overview

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.

This approach comes with the tradeoff of sometimes sending
the same packet multiple times over the Wi-Fi link. However,
in many cases, such as video into a residential home network,
this can be a good tradeoff, since the Wi-Fi link may have enough
capacity for the unicast traffic to be transmitted to each subscribed
STA, even though multicast addressing may have been necessary for
the upstream access network.

Several technologies exist that can be used to arrange unicast
transport over the Wi-Fi link, outlined in the subsections below.

4.5.2. Layer 2 Conversion of Multicast to Unicast

It is often possible to transmit multicast control and data messages
by using unicast transmissions to each station individually.

Although there is not yet a standardized method of conversion, at
least one widely available implementation exists in the Linux bridging
code [ref]. Other proprietary implementations are available from
various vendors. In general, these implementations perform a
straightforward mapping for groups or channels, discovered by IGMP or
MLD snooping, to the corresponding unicast MAC addresses.

4.5.3. Directed Multicast Service (DMS)

DMS was defined in IEEE Std 802.11v-2011, and provides some
enhanced functionality as compared to the Multicast to Unicast
conversion described in Section 4.5.2.

Here are some characteristics of DMS:

o The requesting STA may specify traffic characteristics for DMS
traffic
o Requires 802.11n A-MSDUs
o Requires changes to both AP and STA implementations.

DMS is not currently implemented in products. See [Tramarin2017] and
[Oliva2013] for more information.

4.5.4. Automatic Multicast Tunneling (AMT)

AMT [RFC7450] provides a method to tunnel multicast IP packets
inside unicast IP packets over network links that only support
unicast. When an operating system or application running on a
STA has an AMT gateway capability integrated, it's possible to
use unicast to traverse the Wi-Fi link by deploying an AMT relay
in the non-Wi-Fi portion of the network connected to the AP.

It is RECOMMENDED that multicast-enabled networks deploying AMT relays
for this purpose make the relays discoverable with both of these methods:

o the well-known IP addresses from Section 7 of [RFC7450], and
o with DNS-SD [RFC6763].

Providing the multiple standard discovery methods makes it more
likely that AMT gateway implementations will discover the local
multicast-capable network, rather than forming a connection to an
AMT relay further upstream.
"

I hope that's helpful.

Kind regards,
Jake

On 2018-11-06, 20:46, "Charlie Perkins" <[email protected]> wrote:

Hello Jake,

I'd like to take you up on your offer to provide some text for including
AMT in the document. Also, I reckon a citation will be needed.

If you'd also like to provide some text for use cases that are currently
undeployed (for section 5), I will also include that.

Thanks in advance!

Regards,
Charlie P.

PS. I did change all instances of "client" to be STA. It makes things
more precise, at some cost of readability. I'm not yet sure how I feel
about that.

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