Hi Behcet, Thanks for your review and comments.
>________________________________ > From: Behcet Sarikaya <[email protected]> >To: Dave Thaler <[email protected]> >Cc: Mark Smith <[email protected]>; "[email protected]" <[email protected]>; >"[email protected]" <[email protected]> >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 <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >>> Mark Smith >>> Sent: Thursday, March 28, 2013 8:22 PM >>> To: [email protected] >>> 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: "[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 >>> -------------------------------------------------------------------- >>_______________________________________________ >>MBONED mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/mboned >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
