Re: [MBONED] AMT text requested

["Holland, Jake" <[e-mail]>]

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" <[e-mail]> 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" <[e-mail]> 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" <[e-mail]> 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/mboned