Re: rs-refresh

Hi Erik,

Sorry not to get back to you sooner.

----- Original Message -----
From: Erik Nordmark <nordmark@acm.org>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>; Lorenzo Colitti <lorenzo@google.com>; Erik Nordmark <nordmark@acm.org>
Cc: "6man@ietf.org" <6man@ietf.org>
Sent: Friday, 6 March 2015, 10:18
Subject: Re: rs-refresh

On 3/5/15 12:11 AM, Mark ZZZ Smith wrote:
> I'm generally for the the principle of using link-layer or network layer unicast and replication instead of multicast when replication is cheaper (and arguably it is going to be a lot of the time, because most link layers are actually replicating  frames over point-to-point links to emulate link-layer multicast anyway).
>
> Multicast RAs could be link-layer unicast to individual nodes, once their known, as per RFC6085, so that could be used to reduce/avoid link-layer multicasts by periodic RAs.

Mark,

If we want to enable hosts to sleep, how do you see the router being 
able to schedule when those multicasts-as-unicast will be sent to a 
particular unicast link-layer address? It would seem like that needs to 
be when the host is awake.

/ So I think perhaps there are two separate problems; (a) link-layer multicasts are far less reliable than unicasts on some times of links i.e., 802.11, so protocols that rely on link-layer multicasts can fail and (b) multicasts, regardless of their link-layer reliability, can wake up sleeping devices, which is detrimental to those devices' power consumption.

/ My thinking in this area has mainly been about problem (a), although selectively replicating unicasts at the link-layer to emulate multicasts to specific devices would also address (b), probably to a useful extent. I've also been thinking about it from the perspective of being compatible with existing protocols.

/ So in the context of your RS-Refresh option, I don't see what I've been thinking about as an alternative to it, but instead a way to gain some benefits for legacy hosts that don't support the RS-Refresh option.

>
> For more general multicast traffic, I came up with the following a while back (which I should revisit based on the discussion at the time I posted):
>
> "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6"
> https://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00

That approach would be interesting when the number of members in the 
group are small (and there is no MLD snooping); when the average number 
of members in a group on a link are near one it would perform very well.
But using it for RAs send to all-nodes seems less obvious from a 
performance perspective.

/ I think this technique would perform better in the context of link-layer unicasts being more reliable than link-layer multicasts, and where their is sufficient unicast replication capacity. The main sort of environment I was thinking about when I wrote that was residential Wifi in conjunction with a multicast based IPTV service. Customers had to use wired Ethernet of some form and create a separate LAN/subnet for it because the multicast video traffic would kill their Wifi. At the time I also wrote a utility which could convert between multicast and unicast, and found that for the same video stream, unicast delivery to the receiver was reliable where as multicast wasn't over the same Wifi network.

Regards,
Mark.

Thanks,
    Erik

>
>
>
>
> ________________________________
> From: Lorenzo Colitti <lorenzo@google.com>
> To: Erik Nordmark <nordmark@acm.org>
> Cc: "6man@ietf.org" <6man@ietf.org>
> Sent: Thursday, 5 March 2015, 17:28
> Subject: Re: rs-refresh
>
>
>
>
>
>
> On Thu, Mar 5, 2015 at 2:37 PM, Erik Nordmark <nordmark@acm.org> wrote:
>
> The idea is to provide an option where the network operator can move away from doing periodic multicast RA messages (on links like 3GPP/LTE, or WiFi where it is expensive) and instead have the routers instruct the hosts to send unicast RS messages to refresh the information - get a unicast RA.
> I don't think this is as useful as it appears to be at first glance, for a few reasons:
>      1. This is only useful if all the hosts on the link support it. If one host does not support it, then we fall back to sending multicast RAs again.
>
>      2. Despite what the document says (in two different sections), it is not possible to make it so that "updated nodes can sleep better" AND "preserve the timely and scalable reconfiguration capabilities that a periodic RA model provides" unless there are no legacy hosts on the network
>      3. If the router misses all the RSes from a legacy node (which for a legacy node that doesn't implement resilient RS, means a total of 3 packets sent within 3 seconds of each other, which is quite possible) then that node is blackholed.
>      4. If the router loses state, all legacy nodes are blackholed.
> In general I'd prefer to see what the problems with the RA push model are, and then address those, rather than going to a hybrid push/pull model like this.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>