There seems to be multi-hour delays to the [email protected] mailing address, a copy for reference. I'll make sure all future replies are to [email protected].
----- Forwarded Message ----- > From: Mark Smith <[email protected]> > To: Andrew McGregor <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Friday, 29 March 2013 6:31 PM > Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" > > 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 --------------------------------------------------------------------
