Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"

From: Mark Smith <[email-masked]>
Date: Thu, 28 Mar 2013 22:48:58 -0700 (PDT)

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-masked]" <[email-masked]>
> To: [email-masked]
> 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
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 Mar 2013 20:21:53 -0700 (PDT)

Hi,

Thanks very much,
Mark.

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 29 Mar 2013 17:37:55 +1100

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).

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.

On Fri, Mar 29, 2013 at 2:21 PM, Mark Smith <[email-masked]>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.
>
> > Status:
> http://datatracker.ietf.org/doc/draft-smith-mldv2-link-unicast
> > Htmlized:
> http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00
> >
> >
> > Abstract:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Mar 2013 00:38:37 -0700 (PDT)

There seems to be multi-hour delays to the [email-masked] mailing address, a copy for reference. I'll make sure all future replies are to [email-masked].

----- Forwarded Message -----
> From: Mark Smith <[email-masked]>
> To: Andrew McGregor <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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-masked]>
>> To: Mark Smith <[email-masked]> 
>> Cc: "[email-masked]" <[email-masked]> 
>> Sent: Friday, 29 March 2013 5:37 PM
>> Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of 
> Multicast"
>> 
>> 
> 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-masked]> wrote:
>> 
>> Hi,
>>> 
> 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.
>>> 
> 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).
>>> 
> 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.
>>>

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Mar 2013 00:31:23 -0700 (PDT)

Hi Andrew,

>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-masked]> wrote:
>
>Hi,
>>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 29 Mar 2013 08:49:55 +0100

On 2013-03-29 08:38 , Mark Smith wrote:
> There seems to be multi-hour delays to the [email-masked] mailing
> address, a copy for reference. I'll make sure all future replies are
> to [email-masked].

That is because you are sending mails without directly sending it to
[email-masked] it seems, as such it gets trapped in Mailman with:

8<-------------
Subject:	Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
 	Size:	10605 bytes
 	Reason:	Message has implicit destination
------------->8

The "multi-hour delay" comes from the simple fact that the people who
admin that do tend to sleep sometimes ;)

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 29 Mar 2013 08:55:10 +0100

> [email-masked] it seems, as such it gets trapped in Mailman with:

And seeing the mail more closely, you are sending to [email-masked],
which is apparently aliased and is the right name for the WG, though the
list name is ipv6@....

I've kicked mailman so that it handles 6man@ as an alias, that should
resolve this issue.

Greets,
 Jeroen

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 09:04:26 +0100

On Mar 29, 2013, at 07:37, Andrew McGregor <[email-masked]> wrote:

> IPv6 over 802.11

That doesn't really exist; IP is generally interfacing to 802.11 as if it were 802.3.

There was some discussion at IETF 60, apparently, but I don't know of any results:
http://tools.ietf.org/html/draft-daniel-ipv6-over-wifi-01 was 2004.

I was trying to address the general issue of how to do optimizations on networks that aren't Ethernets, but for all intents and purposes are treated like Ethernets, at about the same 
time in http://tools.ietf.org/html/draft-bormann-rohc-over-802 -- but there was little 
interest.

With the recent attention on 802 issues in Orlando, maybe it's time to look closer again.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 09:21:13 +0100

Hi Mark,

interesting draft.  I'm interested in this from a 6LoWPAN perspective -- everything we can do to get rid of multicasts is very good for 6LoWPANs.

I don't understand how you think NUD would work with this (3.2) -- are you saying that the multicast emitter actively runs NUD to the targets?

MLDv2 is a protocol that runs between multicast listeners and multicast routers.
How do you handle multicast emitters that aren't multicast routers?

How do you wean MLDv2 itself off multicast?  (Now that would be my holy grail.  We didn't get around to do this in RFC 6775 -- we didn't think we'd have to, since we were addressing a subnet where subnet-multicast doesn't work at all.)  Maybe efficient-ND could do something here.

Grüße, Carsten

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Mar 2013 02:52:20 -0700 (PDT)

Hi Carsten,

----- Original Message -----
> From: Carsten Bormann <[email-masked]>
> Sent: Friday, 29 March 2013 7:21 PM
> interesting draft.  I'm interested in this from a 6LoWPAN perspective -- 
> everything we can do to get rid of multicasts is very good for 6LoWPANs.
> 
> I don't understand how you think NUD would work with this (3.2) -- are you 
> saying that the multicast emitter actively runs NUD to the targets?
> 

Yes. NUD is performed on the link-local addresses used as the source addresses for the MLDv2 messages.

Originally when I was thinking about this, I thought that might be one of the things that would need to be changed. However, when I reviewed the part of RFC3810 (MLDv2) related to MLD Report source addresses, I came across the following in 5.2.13, "Source Addresses for Reports":

   On the other hand, routers MUST silently discard a message that is
   not sent with a valid link-local address, without taking any action
   on the contents of the packet.  Thus, a Report is discarded if the
   router cannot identify the source address of the packet as belonging
   to a link connected to the interface on which the packet was
   received.  A Report sent with the unspecified address is also
   discarded by the router.  This enhances security, as unidentified
   reporting nodes cannot influence the state of the MLDv2 router(s).

It seems to me that the only way to be sure a MLDv2 source link-local address is valid and belongs to the link is to test it's existence, which is of course what neighbor discovery does using an NS/NA transaction. So the existing ND neighor presence discovery mechanism can, and I think the above implies should be used to determine MLDv2 link-local source address validity, and therefore the ND NUD mechanism can then be used to determine when the neighbor disappears, and therefore link-layer unicasting of mulicast IPv6 should stop for that now absent listener.

(Out of interest, I checked to see if this sort of link-local address validity checking is being performed by Linux and one of the BSDs (I can't remember which one). Neither of them did, all they checked was that the source address of the MLDv2 report was a link-local address. So they're vulnerable to MLDv2 reports with spoofed, non-existent link-local addresses ...)

> How do you handle multicast emitters that aren't multicast routers?

The main use case scenario I've been thinking about is multicast IPTV over a carrier network, towards a residential customer, where the last hop in the customer's home is 802.11, and where the multicast performance problems appear. So the multicast source servers would be wired, and on segments where the volumes of multicast traffic didn't impact link performance.

My main overriding goals were to avoid changes to the end-hosts, leaving changes to be made to the multicast router's behaviour (e.g. residential CPE), and to reduce the number of multicasts as much as possible, but not eliminate them. Low levels of multicast on 802.11 works ok, it's the high levels that cause problems.

If a host implementation can be changed, then it could implement the procedures I've described. It could listen to the MLDv2 reports (as non-Querier multicast routers do), do neighbor discovery/NUD on the MLDv2 source link-local addresses, and then proceed to link-layer unicast the multicast IPv6 traffic to its on-link neighbors.

> How do you wean MLDv2 itself off multicast?  (Now that would be my holy grail.  
> We didn't get around to do this in RFC 6775 -- we didn't think we'd 
> have to, since we were addressing a subnet where subnet-multicast doesn't 
> work at all.)  Maybe efficient-ND could do something here.
> 

I've put a little bit of thought into this. If you're able to change the host and the router implementations, then I've thought might be able to eliminate multicasts by treating the broadcast/multicast link as a Non-Broadcast Multi-Access link, and then use RFC2491, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" methods. Briefly looking at it, it does mention how to handle the SMDS link layer, and my understanding is that was a connectionless (rather than a connection oriented) NBMA link-layer, so treating 802.11 or 802.3 as an NMBA link could probably use the NBMA IPv6 techniques used for SMDS.

Regards,
Mark.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 11:07:13 +0100

> Yes. NUD is performed on the link-local addresses used as the source addresses for the MLDv2 messages.

RFC 4861 says:

   Neighbor Unreachability Detection detects the failure of a neighbor
   or the failure of the forward path to the neighbor.  Doing so
   requires positive confirmation that packets sent to a neighbor are
   actually reaching that neighbor and being processed properly by its
   IP layer.  Neighbor Unreachability Detection uses confirmation from
   two sources.  When possible, upper-layer protocols provide a positive
   confirmation that a connection is making "forward progress", that is,
   previously sent data is known to have been delivered correctly (e.g.,
   new acknowledgments were received recently).  When positive
   confirmation is not forthcoming through such "hints", a node sends
   unicast Neighbor Solicitation messages that solicit Neighbor
   Advertisements as reachability confirmation from the next hop.  To
   reduce unnecessary network traffic, probe messages are only sent to
   neighbors to which the node is actively sending packets.

See also
7.3.1.  Reachability Confirmation

   In some cases (e.g., UDP-based protocols and routers forwarding
   packets to hosts), such reachability information may not be readily
   available from upper-layer protocols.  When no hints are available
   and a node is sending packets to a neighbor, the node actively probes
   the neighbor using unicast Neighbor Solicitation messages to verify
   that the forward path is still working.

So your multicast emitters would be NS-pinging their destinations all the time?
Probably not too onerous for your TV scenario (with REACHABLE_TIME at 30 s), and a good way to shutdown traffic to a hard-failed receiver before the MLDv2 timeouts kick in, but
maybe not that great in a constrained network that only occasionally sends multicast packets.

(Incidentally, 4861 also says:
   Neighbor Unreachability Detection is performed only for neighbors to
   which unicast packets are sent; it is not used when sending to
   multicast addresses.
So this would then have to be adapted, because it's no longer an either/or with 6085.)

Grüße, Carsten

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Mar 2013 03:26:42 -0700 (PDT)

Hi Carsten,

----- Original Message -----
> Cc: "[email-masked]" <[email-masked]>
> Sent: Friday, 29 March 2013 9:07 PM

Yes, that is correct.

> Probably not too onerous for your TV scenario (with REACHABLE_TIME at 30 s), and 
> a good way to shutdown traffic to a hard-failed receiver before the MLDv2 
> timeouts kick in, but

The constrained devices/constrained bandwidth domain is not the one I'm addressing. My focus has been "unicast performs well, sufficient CPU to replicate and unicast packets is cheap and available, low level multicast is acceptable, high level multicast is a problem" domain, although some of the other secondary benefits could make it useful in more than just 802.11 networks. I agree, the efficiencies it provides probably aren't enough for it to be useful in a 6Lowpan scenario.

> So this would then have to be adapted, because it's no longer an either/or 

That's a good point.

Thanks very much,
Mark.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 29 Mar 2013 20:55:21 +0000

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-masked] [mailto:[email-masked]] On Behalf Of
> Mark Smith
> Sent: Thursday, March 28, 2013 8:22 PM
> To: [email-masked]
> Subject: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
> 
> Hi,
> 
> 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.
> 
> (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
> 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.
> 
> > has been successfully submitted by Mark Smith and posted to the IETF
> > repository.
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 29 Mar 2013 16:33:58 -0500

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. I suggest you take a look at
http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01
on Netext for PMIPv6.

I believe that we should use multicast delivery as much as possible on the
downlink if the link is a shared link.

Regards,

Behcet

On Fri, Mar 29, 2013 at 3:55 PM, Dave Thaler <[email-masked]> wrote:

> worth spending
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Mar 2013 14:40:10 -0700 (PDT)

Hi Dave,

Thanks very much for those references. I'll have a read, and refer to them in the next revision.

Thanks also for pointing out the MBoneD WG.

Best regards,
Mark.

----- Original Message -----
> From: Dave Thaler <[email-masked]>
> To: Mark Smith <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Saturday, 30 March 2013 7:55 AM
> Subject: RE: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
> 
> there

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Mar 2013 15:18:06 -0700 (PDT)

Hi Behcet,

Thanks for your review and comments.

> From: Behcet Sarikaya <[email-masked]>
>To: Dave Thaler <[email-masked]> 
>Cc: Mark Smith <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>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
>
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 Mar 2013 05:16:50 +0100

On Mar 29, 2013, at 23:18, Mark Smith <[email-masked]> wrote:

>> The main use case

I certainly can sympathize with this use case.

I'm more interested in solutions that scale, up and down.

When we did 6LoWPAN-ND to get rid of the requirement for subnet-wide multicast, we stuck to the constrained node network use case because it was already hard enough to get right.  To address scaling up, efficient-ND is now tackling the even more challenging transition problem as well, but that is its only major source of added complexity.

I'm using this as a parable to say: If we can do something that solves your and my problem, and is only marginally more complex, we should do it.  Interfacing to efficient-ND as well might be one component of that.  Efficient-MLD?  Just brainstorming at this point.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2013 22:23:17 -0400

Could some combination of IGMPv3 and ND signal to whatever is sending
doing the layer-2 multicast operations (e.g. the sender, or the router)
that the receiver would prefer to be receive layer-2 unicasts?

That could therefore happen at the IGMP aware switch, etc.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [