Hi Andrew, Thanks very much for your review and comments.
>________________________________ > From: Andrew McGregor <[email protected]> >To: Mark Smith <[email protected]> >Cc: "[email protected]" <[email protected]> >Sent: Friday, 29 March 2013 5:37 PM >Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" > > >Isn't this something that could be done entirely at the sub-IP layer for link >technologies where this is an issue? I'd argue that all multicast in 802.11 >is badly broken, and should be fixed at that layer (multicast can be more than >50x slower than unicast, and packet loss can approach 80% while unicast is >working fine... this is not good). > > >Overcoming 802.11 multicast performance limitations is the main reason for >what I've proposed, however I think there are a number of other advantages >even when this technique is used on non-802.11 link-layers. > > > >I don't know if MLDv2 snooping is available or even possible on 802.11 APs. >This technique would fill that gap if not. > > >That said, perhaps there is call for doing multicast fan-out at the IP layer >as well, for cases where the underlying link has 802.11-like multicast >characteristics that cannot be fixed for whatever reason. Perhaps the IETF >should even suggest that IPv6 over 802.11 should switch to this proposal, as >it would improve performance dramatically while the 802.11 layer remains >unfixed; there will be legacy APs around for a very long time. > > >I think the advantage of doing it at layer 3 are that it can be applied to any >link-layer, including future ones; doesn't require layer violations as doing >it at the sub-IP layer would/does, as ND has complete knowledge of layer >3/layer2 mappings, and MLDv2 can have complete knowledge of the link-local >layer 3 addresses of its listeners; has some security value by increasing data >confidentiality compared to link-layer multicasts; and will probably benefit >mobile devices with batteries by reducing the amount of multicasts they end up >ignoring. > > >Regards, >Mark. > > >On Fri, Mar 29, 2013 at 2:21 PM, Mark Smith <[email protected]> wrote: > >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: "[email protected]" <[email protected]> >>> To: [email protected] >>> 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 >>[email protected] >>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
