Re: AMT text requested

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