Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 03 April 2013 17:11 UTC
Return-Path: <sarikaya2012@gmail.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 5D57821F8FCF; Wed, 3 Apr 2013 10:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.348
X-Spam-Level:
X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOwKwx2B7-+l; Wed, 3 Apr 2013 10:11:31 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 34FAA21F8FA1; Wed, 3 Apr 2013 10:11:30 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id p11so1847363lbi.0 for <multiple recipients>; Wed, 03 Apr 2013 10:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DSQP4Qa588zGY/18K94JMLiGCIWYcsv/3M86/6+CQns=; b=hWWaKhO/9Y+Z1UzgWj09zBZeNmeuoJNHRNiTBGg+iuSZFuXBGIfAZRg+kqAaLSxKxS BlarV9KJMuOfAMWSc/scdYRCB3NQG/qY+lkTCbhsro7rTBq2TISmIFplidlMflLEKAEo mbPqTbkqXusYBbeaHBzjd1Llwu3dO1WsVtFvvgYDDEI5ThrV/VSvlAtNeAjZiPKjkC+D giIHlFIa7iOZ4CG6fdKvbWpNzk6/SzNpvTf6CaZr/t8VetEqwLHvLWBFtO+oTqNSjkKu mZ94R8CmjQGF/XVkh1H0ZnAw5gHdS2pkhzUdgXDDtqmKOYzJl4bIbF9cuFmvdAfIkwbj aXqg==
MIME-Version: 1.0
X-Received: by 10.112.129.137 with SMTP id nw9mr1547346lbb.56.1365008599366; Wed, 03 Apr 2013 10:03:19 -0700 (PDT)
Received: by 10.114.17.104 with HTTP; Wed, 3 Apr 2013 10:03:19 -0700 (PDT)
In-Reply-To: <20130401205621.GG23316@cisco.com>
References: <20130329024509.29249.3948.idtracker@ietfa.amsl.com> <1364527313.7097.YahooMailNeo@web142504.mail.bf1.yahoo.com> <44E744236D325141AE8DDC88A45908AD0C9BBE@TK5EX14MBXC264.redmond.corp.microsoft.com> <CAC8QAcehc4VzU3zDEJrH-FkDDPWPpH6+1pwEHh_VLd1693PvuA@mail.gmail.com> <1364595486.62793.YahooMailNeo@web142506.mail.bf1.yahoo.com> <20130401205621.GG23316@cisco.com>
Date: Wed, 03 Apr 2013 12:03:19 -0500
Message-ID: <CAC8QAceqFCyiyHa8CXZFoSjRa9qnfHEB8c+eZ44pkEzLAO9S1Q@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Toerless Eckert <eckert@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b3a7f10ae417e04d977d4d8"
Cc: "mboned@ietf.org" <mboned@ietf.org>, Mark Smith <markzzzsmith@yahoo.com.au>, "6man@ietf.org" <6man@ietf.org>
Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
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: <http://www.ietf.org/mail-archive/web/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: Wed, 03 Apr 2013 17:11:33 -0000
On Mon, Apr 1, 2013 at 3:56 PM, Toerless Eckert <eckert@cisco.com> wrote: > Bunch of comments... > > 1. What Mark is proposing is being done AFAIK in a variety of products on > the market, > for example as the "multicast to unicast" eleement of Cisco VideoStream > and i think other vendors do this as well. Not sure about IPv6 though, > i've only seen > it in IPv4. > > 2. I am always getting annoyed when IPv6 bigots oops: fans unnecessarily > constraining > solutions to IPv6 only even though they equally apply to IPv4 and, in > the case > of IP multicast when its clear that the mayority of use for a while > will still be > IPv4. Its already bad enough that RFC6085 was written only for IPv6 > instead of > for IPv4 and IPv6. I explained why already: it was for PMIPv6 which needed to have point-to-point link on 802.11. For the rest of this very long message, yes, this is an application issue and I don't see why IETF should enter into this domain. Behcet > It would be lovely if Marks draft could be modified to cover > both IPv4 and IPv6. I can't remember that RFC6085 was given for review > to MBoned, > or else i'd hae made that comment for it as well. But see 1: in > practice existing > IPv4 host stacks will wwell receive DMAC-unicast IP multicast packets > due to the > fundamental separation of L3 and L2 in the architecture of most host > stacks. > > 3. I think a key eleemnt of the draft that should be made more clear in > the description is > that this mechanism is meant to be incrementally dpeloyable such that > the mayority > of devices on the (wireless) L2 domain do not have to be changed at > all, and that > the only expection against them is 2. (RFC6085 or equivalent for IPv4). > > To achieve this, the only requirement is to run IGMPv3/MLDv2, inhibit > MLDv1/IGMPv1v2, > and a device that wants to send multicast as unicast into the L2 domain > needs to > perform explicit tracking of the membership reports to know whom to > send unicast copies to. > > And then there are optimizations such as RFC4861 which should be > optional. > > But having said all this, the fact that this can be done as a local > implementation > optimization in a device sending IP multicast into the L2 domain > (whether thats > a router, switch, host or whatever), it also means that this mechanism > does not > need to change any protocol signaling, and therefore the question is > whether this > can be standards track or just be informational. > > 4. I don't particularily think that the operating models presented and the > first > sentence of the abstract are correct. Sending L2 (wireless) multicast > has a lot of > benefits, and it has a lot of downsides. It totally depends on what you > try to achieve. > > It is clear that 802.11 is particularily challenged with native L2 > multicast because > they never defined a good resilience scheme as for unicast but so far > not for multicast. > Hopefully this will get fixed sometime. As long as thats not the case > we definitely > have to tke this into account as a constraint, but it would be good to > explain the > situation correctly in the doc. > > Wrt. the operational model, i could easily see that one wold start out > with unicasting, > but then change over to multicasting for a particular group/channel > when the > total number of receivers tracked and bandwidth sent over the > group/channel is too large. > You may also limit IP multicast to a particular bitrate, so if a > specific receiver > can not support that bitrate, it would need to get unicast, and then > that unicast > might need to be rate-limited so that the receiver downspeeds (assuming > it is > using ALC which it really should). I am not aware if any product > embodies > this dyanmicac switching, i am just saying it sounds logical to me ;-) > > So, given how many policies there could be to improve behavior of > multicast over > wireless, i think it would be more appropriate to make this draft > informational > and collect/document/discss these possible policies. Its not as if a > specific individual > policy seems to be ubiquoutously preferrable, and given how its all > local policy on the > device sending into the wireless L2, it doesn't seem to be the right > place for a > standard track doc. Going informational does hopefully not make a > difference for > this doc being useful, because whether its standards track or not, > customers will hopefully > put it into RFPs against their wireless equipment. Which also means its > a good idea > in these type of documents to give sticky names to individual functions > such as > different type of policies or optimizations, so customes in RFPs can > refer to those > sticky names (or section numbers). > > 5. Not being really a protocol extension but logically device-local > improvements with > a bunch of policies possible makes it also a good candidate for MBoned > as opposed to a > protocol group (i think... ). > > Cheers > Toerless > > tracking of > that it is consisting purely of mechanisms that the accss-point type > device in a > > > On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote: > > Hi Behcet, > > > > Thanks for your review and comments. > > > > > > > > >________________________________ > > > From: Behcet Sarikaya <sarikaya2012@gmail.com> > > >To: Dave Thaler <dthaler@microsoft.com> > > >Cc: Mark Smith <markzzzsmith@yahoo.com.au>; "6man@ietf.org" < > 6man@ietf.org>; "mboned@ietf.org" <mboned@ietf.org> > > >Sent: Saturday, 30 March 2013 8:33 AM > > >Subject: Re: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery > of Multicast" > > > > > > > > >Hi Mark, > > > > > >I read your draft. > > >First of all I think you misunderstood RFC 6085 and based on a wrong > assumption you developed your solution. > > > > > > > > >What specifically do you think I've misunderstood? I was involved in > some of the conversations about that RFC while it was an ID, and all I > think it really is fundamentally saying is that an IPv6 packet with a > multicast IPv6 destination address isn't required to have a link-layer > multicast destination address - it can be a link-layer unicast destination > address if useful or necessary. > > > > > > > > > > > > > > > I suggest you take a look at > http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 > > >on Netext for PMIPv6. > > > > > > > > >I'll have a read. > > > > > >I believe that we should use multicast delivery as much as possible on > the downlink if the link is a shared link. > > > > > > > > > > > > > > >I agree with using multicast as much as possible to reduce duplicate > packets sent over the network. The proposal here is to use packet > replication and link-layer unicasts when doing so would either exceed the > performance of link-layer multicast and/or overcome the negative effects of > link-layer multicast, such as when larger volumes of multicast traffic > impact unicast performance on the same link. Both of these issues occur on > 802.11 links when there volume of multicast traffic is in the order of a > few megabits (or less, I've been testing with around 2.5 Mbps of video) > > > > > > > > >The main use case I've been thinking about (which I'll make more > obvious in the next revision), is a multicast IPTV service scenario towards > a residential customer, where the residential customer has a 802.11 network > in their home rather than a wired one. IPv6 multicast/link-layer multicast > would be used all the way from the multicast source servers, across the > service provider network, up until the CPE in the residential customers' > homes, gaining the efficiencies of multicast. However, the CPE in the > customer's house would then use IPv6 multicast/link-layer unicast of the > IPTV traffic over the 802.11 link to the customers end-hosts, saving them > having to put in wired infrastructure, or resorting to buying ethernet over > power devices to make their power cabling their wired infrastructure. Note > that there is still a low level of link-layer multicast traffic in the > customers home, for RAs, ND, MLDv2 messages, DHCPv6, etc.. This proposal is > not eliminating > > link-layer multicasts, just reducing them where possible and where > useful. > > > > > > > > >That's not to say this proposal is only useful in an 802.11 scenario. > It could be used in any scenario where packet replication and link-layer > unicasting would provide useful benefits over link-layer multicasts. It > generally increases the data confidentiality of the multicast IPv6 traffic, > and may help increase battery life of some devices. > > > > > > > > >Thanks very much, > > >Mark. > > > > > > > > > > > >Regards, > > > > > >Behcet > > > > > > > > > > > > > > >On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler <dthaler@microsoft.com> > wrote: > > > > > >http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast > > >>is work we did back in 2000 on this same topic. At the time, the > draft is written from > > >>the perspective of the 6to4 NBMA link, but the topic was discussed > (specifically by those > > >>in the acknowledgements section, and to a lesser extent by the ngtrans > WG as a whole) > > >>as being more generally applicable. > > >> > > >>There wasn't significant interest at the time and so the work was > dropped > > >>rather than updating the spec to use generic language. > > >> > > >>The same concept as in the above was however then used in 2001 in > > >>http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast > > >>(still specific to a particular link type though), which after 11 > years is now in the IESG :) > > >> > > >>The most relevant WG is MBoneD. > > >> > > >>-Dave > > >> > > >> > > >>> -----Original Message----- > > >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > > >>> Mark Smith > > >>> Sent: Thursday, March 28, 2013 8:22 PM > > >>> To: 6man@ietf.org > > >>> Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of > Multicast" > > >>> > > >>> Hi, > > >>> > > >>> The following is inspired by some work I did in around 2010/2011 on a > > >>> multicast TV service, where residential customers with Wifi networks > > >>> suffered from performance problems, and had to be advised to buy > > >>> ethernet over power devices if they couldn't run wired ethernet to > the STB > > >>> attached to their TV. > > >>> > > >>> I've done some experiments on my home wifi network, using VLC, and > > >>> switching between multicast and unicast IPv6 to test the concept. > The wifi > > >>> performance issues disappear when the video is delivered via unicast > UDP. > > >>> (If people want to play with VLC and IPv6 multicast, email me > off-list, as there > > >>> are a few issues e.g. the GUI doesn't accept some of the IPv6 > multicast > > >>> parameters that the command line does). > > >>> > > >>> I think there is a possibility the technique could also be applied to > > >>> IGMPv3/ARP, although it depends on whether ARP has been implemented > > >>> in a similar manner to IPv6 ND (e.g. an ARP equivalent to NUD). My > > >>> understanding is that Linux has implemented ARP this way. I'll do > some more > > >>> research to verify this. > > >>> > > >>> I though I'd post it to see if there is merit in the idea and it is > worth spending > > >>> more of my time on. I looked for a IETF group more suitable to this, > but didn't > > >>> seem to be able to find one. If there is one, please let me know. > > >>> > > >>> Review and comments most appreciated. > > >>> > > >>> Thanks very much, > > >>> Mark. > > >>> > > >>> > > >>> ----- Forwarded Message ----- > > >>> > From: "internet-drafts@ietf.org" <internet-drafts@ietf.org> > > >>> > To: markzzzsmith@yahoo.com.au > > >>> > Cc: > > >>> > Sent: Friday, 29 March 2013 1:45 PM > > >>> > Subject: New Version Notification for > > >>> > draft-smith-mldv2-link-unicast-00.txt > > >>> > > > >>> > > > >>> > A new version of I-D, draft-smith-mldv2-link-unicast-00.txt > > >>> > has been successfully submitted by Mark Smith and posted to the > IETF > > >>> > repository. > > >>> > > > >>> > Filename: draft-smith-mldv2-link-unicast > > >>> > Revision: 00 > > >>> > Title: MLDv2 Procedures for Link-Layer Unicast Delivery of > > >>> > Multicast > > >>> > IPv6 > > >>> > Creation date: 2013-03-29 > > >>> > Group: Individual Submission > > >>> > Number of pages: 7 > > >>> > URL: > > >>> > > http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00. > > >>> > txt > > >>> > Status: > > >>> > http://datatracker.ietf.org/doc/draft-smith-mldv2-link-unicast > > >>> > Htmlized: > > >>> > http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 > > >>> > > > >>> > > > >>> > Abstract: > > >>> > Some multi-access link-layer technologies typically not provide > > >>> > good > > >>> > IPv6 multicast performance, using link-layer multicasts, when > the > > >>> > volume of multicast traffic is significant. It would be > possible > > >>> > to > > >>> > replicate and then link-layer unicast multicast IPv6 traffic to > > >>> > interested listeners to overcome these link-layer performance > > >>> > limitations. This memo describes MLDv2 and IPv6 neighbor > discovery > > >>> > procedures to support link-layer unicast delivery of multicast > IPv6 > > >>> > traffic. > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > The IETF Secretariat > > >>> > > > >>> -------------------------------------------------------------------- > > >>> IETF IPv6 working group mailing list > > >>> ipv6@ietf.org > > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > >>> -------------------------------------------------------------------- > > >>_______________________________________________ > > >>MBONED mailing list > > >>MBONED@ietf.org > > >>https://www.ietf.org/mailman/listinfo/mboned > > >> > > > > > > > > > > > _______________________________________________ > > MBONED mailing list > > MBONED@ietf.org > > https://www.ietf.org/mailman/listinfo/mboned > > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! > >
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Dave Thaler
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Behcet Sarikaya
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Mark Smith
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Mark Smith
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Carsten Bormann
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Behcet Sarikaya
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Behcet Sarikaya
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Manfredi, Albert E
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Toerless Eckert
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Mark Smith
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Toerless Eckert
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Carsten Bormann
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Toerless Eckert
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Carsten Bormann
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Christian Huitema
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Christian Huitema
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Andrew McGregor
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Behcet Sarikaya
- Re: [MBONED] "MLDv2 Procedures for Link-Layer Uni… Mark Smith