Re: rs-refresh

On 3/16/15 5:26 PM, Mark ZZZ Smith wrote:
>
> 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.

Mark,

There is a 3rd which is the key one for hosts that want to sleep; the 
router sending a (unicast or multicast) packet at a random periodic time 
isn't useful. Either it is ignored/dropped (because the host is 
sleeping), or it forces the host to wake up.

>
> / 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.
Replicated unicast would clearly help with the reliability of the 
transmission.

AFAICT it wouldn't help with the other robustness issues listed in the 
dad-issues draft.

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

Yes, that is an area where multicast as unicast would help.

FWIW there is also some work in IEEE 802.11aa on Reliable Multicast 
which seems to target video-type streams.

    Erik

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