Re: [MBONED] AMT text requested
"Holland, Jake" <jholland@akamai.com> Tue, 02 April 2019 18:34 UTC
Return-Path: <jholland@akamai.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21703120192; Tue, 2 Apr 2019 11:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=0.85, 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=akamai.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 FXBEjtTjs0uc; Tue, 2 Apr 2019 11:34:55 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 8EFAE12018D; Tue, 2 Apr 2019 11:34:55 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x32IYctm025038; Tue, 2 Apr 2019 19:34:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Lave9+lPm4P5uQJGFpAybBlKRCAJC1G34H94FszEbWs=; b=H8PVUm0HKQqTqv0yd2sw37f9Ut/8yy/QpeUKFB8LYki3H3XgUx6qGB8RH1CLYUj1txyc jUA9sKG6qh7xYJX3IlUYIa3dFN4NW/VgMoMhiNsbMrWvnSk1MyMH6qFflRrMm3T8jMo2 HumMDU8BlR8EictPYXjk6HhhLlDdFkPongLNamn/Ojo3HMNctbgXnfGHL+6/PLfpXqK6 t/UkcrQqkmPZacaw/NNznKSW3TqLYUkYVmnTFXBa1suIIqFTdjB81QBRUkomD4Pnxltk l8Pok+g0Cr6/S54Pnnj2X4OJAziFpG8fiVw4XGqODyVihLchmENdZCUANEYeg4OadPKP iw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2rm5dk1ppq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Apr 2019 19:34:52 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x32IWDDZ028677; Tue, 2 Apr 2019 14:34:51 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2rmcsh82u8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Apr 2019 14:34:51 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 13:34:48 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.003; Tue, 2 Apr 2019 13:34:48 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: Charlie Perkins <charles.perkins@earthlink.net>
CC: "draft-ietf-mboned-ieee802-mcast-problems@ietf.org" <draft-ietf-mboned-ieee802-mcast-problems@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
Thread-Topic: AMT text requested
Thread-Index: AQHUdlTPVPdFPP9slkuriIQZlw7eU6VOJTsAgNxo9AA=
Date: Tue, 02 Apr 2019 18:34:48 +0000
Message-ID: <2508EC76-FD54-49FE-9382-1FF5FED3D7B0@akamai.com>
References: <49d3f0ab-b2f7-04b9-488b-91e22510e0eb@earthlink.net> <8A18568C-6884-43D2-9E52-9D1C193BCB44@akamai.com>
In-Reply-To: <8A18568C-6884-43D2-9E52-9D1C193BCB44@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.1.190326
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.115.79]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F137B42F45411441A482B654E6FAEFF9@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904020124
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904020124
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/fgOP-gyVy3KuPC17rwBENJLMiR0>
Subject: Re: [MBONED] AMT text requested
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 18:34:58 -0000
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" <jholland@akamai.com> 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" <charles.perkins@earthlink.net> 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.
- Re: [MBONED] AMT text requested Holland, Jake
- Re: [MBONED] AMT text requested Holland, Jake