Subject: rs-refresh

From: Erik Nordmark <[email-masked]>
Date: Wed, 04 Mar 2015 21:37:52 -0800

Before Honolulu I uploaded 
https://tools.ietf.org/html/draft-nordmark-6man-rs-refresh-00 and this 
draft was mentioned (and briefly discussed) in the efficient-nd design 
team slides.

Do folks think this makes sense? As a 6man WG document?

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.

This would be optional - there are links where periodic multicast RAs 
are both efficient and reliable and there is no need to change that for 
those links.

Comments welcome,
    Erik

---

From: MATSUSHIMA Satoru <[email-masked]>
Date: Thu, 5 Mar 2015 14:58:24 +0900

That makes sense. I support this draft to be a WG document.

cheers,
—satoru

2015/03/05 14:37、Erik Nordmark <[email-masked]> wrote：

> Before Honolulu I uploaded https://tools.ietf.org/html/draft-nordmark-6man-rs-refresh-00 and this draft was mentioned (and briefly discussed) in the efficient-nd design team slides.
> 
> 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.
> 
> This would be optional - there are links where periodic multicast RAs are both efficient and reliable and there is no need to change that for those links.
> 
> Comments welcome,
>   Erik
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Mar 2015 15:28:01 +0900

On Thu, Mar 5, 2015 at 2:37 PM, Erik Nordmark <[email-masked]> 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.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 5 Mar 2015 08:11:59 +0000 (UTC)

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. 

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

________________________________
From: Lorenzo Colitti <[email-masked]>
To: Erik Nordmark <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Thursday, 5 March 2015, 17:28
Subject: Re: rs-refresh

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.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 05 Mar 2015 15:02:50 -0800

On 3/4/15 10:28 PM, Lorenzo Colitti wrote:
> On Thu, Mar 5, 2015 at 2:37 PM, Erik Nordmark <[email-masked] 
> <mailto:[email-masked]>> 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.
>
>
>  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
>

Lorenzo,

I think you are missing the difference between the host and router behavior.
True that to support unmodified hosts *the routers* would need to 
continue to multicast unsolicited RAs.
But *the hosts* that perform the rs-refresh can sleep without having to 
wake up due to those RAs.

>  1. 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.
>
That is an issue that is independent and resilent-rs already solves it.
>
>  1. If the router loses state, all legacy nodes are blackholed.
>
What part of the draft leads you to that (incorrect) conclusion? I can 
definitely clarify that it does not.
Nothing in the draft removes part of section 6.2.4 in RFC4861 about 
sending MAX_INITIAL_RTR_ADVERTISEMENTS initial unsolicited RAs.

> 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.
We discussed draft-garneij-6man-nd-m2m-issues (which points out problems 
in large cellular networks) in the efficient-nd design team and you were 
present during those discussions.

Regards,
     Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 05 Mar 2015 15:18:39 -0800

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

Thanks,
    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Mar 2015 08:41:22 +0900

On Fri, Mar 6, 2015 at 8:02 AM, Erik Nordmark <[email-masked]> wrote:

> True that to support unmodified hosts *the routers* would need to continue
> to multicast unsolicited RAs.

But at least as far as I can see they can't sleep if there are legacy hosts
on link, unless you break the current semantics of RAs.

Let me try to state that another way. The draft seems to imply that with
this scheme you can have all of the following:

   1. "Preserve the timely and scalable reconfiguration capabilities that a
   periodic RA model provides"
   2. Allow updated nodes to sleep.
   3. Support legacy hosts on the network.

But you can't, right? The reason you can't is that #3 requires that
multicast RAs be sent periodically to ensure non-updated hosts. But if
you're sending multicast RAs periodically, then the updated nodes either
sleep and ignore them (in which case you can't reconfigure them
dynamically, which means you lose the current capabilities of RAs to
rapidly disseminate new information, i.e., you get #2 but not #1), or the
updated nodes stay awake, in which case you get #1 but not #2.

>>  That is an issue that is independent and resilent-rs already solves it.

But there are billions of existing nodes that do not support resilient-rs.
Suppose one of those nodes joins the network when there were none before,
and for some reason the router misses all three RS packets. How will the
router know that it's there and thus it needs to send periodic RAs?

> sending MAX_INITIAL_RTR_ADVERTISEMENTS initial unsolicited RAs.

Unless I'm misreading that section, sending
MAX_INITIAL_RTR_ADVERTISEMENTS is only a MAY, so it can't be relied on.

>> are, and then address those, rather than going to a hybrid push/pull model
>> like this.
>>

What part of that problem cannot be solved by upping the maximum value for
MaxRtrAdvInterval? The calculations in the draft use a value of 1800, which
is 5 times less than the current maximum, and 36 times less than the
maximum value that can be stored in the packet.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Mar 2015 22:21:57 -0700

On 3/5/15 3:41 PM, Lorenzo Colitti wrote:
> On Fri, Mar 6, 2015 at 8:02 AM, Erik Nordmark <[email-masked] 
>     But *the hosts* that perform the rs-refresh can sleep without
>     having to wake up due to those RAs.
>
>
> But at least as far as I can see they can't sleep if there are legacy 
> hosts on link, unless you break the current semantics of RAs.
>
> Let me try to state that another way. The draft seems to imply that 
> with this scheme you can have all of the following:
>
>  1. "Preserve the timely and scalable reconfiguration capabilities
>     that a periodic RA model provides"
> multicast RAs be sent periodically to ensure non-updated hosts.
That isn't actually the case. See below.
> But if you're sending multicast RAs periodically, then the updated 
> nodes either sleep and ignore them (in which case you can't 
> reconfigure them dynamically, which means you lose the current 
> capabilities of RAs to rapidly disseminate new information, i.e., you 
> get #2 but not #1), or the updated nodes stay awake, in which case you 
> get #1 but not #2.

Not quite.

It depends on how we think the hosts should handle DNA and whether that 
is invoked each time the host wakes up from sleep, or whether DNA can be 
suppressed based on some l2 information.

If DNA is not suppressed, then the text in 7.2 applies:

      7.2
      <https://tools.ietf.org/html/draft-nordmark-6man-rs-refresh-00#section-7.2>.
      Movement

    When a host wakes up it can combine movement detecting (DNA), NUD,
    and refreshing its prefixes etc by sending a unicast RS to each of
    its existing default router(s).

This unicast RS serves to get the new configuration information when the 
host wakes up.
(Note that there is also a listed open issue whether we want to optimize 
the "nothing changed" case by having some epoch number in the RA and RS.)

Given the needs of NUD I think it would make sense to require hosts to 
unicast a RS when upon wakeup (or strictly speaking, as part of using 
the network upon wakeup - if the host only wakes up to display the time 
there is no need for this). I think we can make this a requirement for 
the hosts that want to sleep while ignoring multicast RAs.

> But there are billions of existing nodes that do not support 
> resilient-rs. Suppose one of those nodes joins the network when there 
> were none before, and for some reason the router misses all three RS 
> packets. How will the router know that it's there and thus it needs to 
> send periodic RAs?

It depends on the operational environment. Some environments might be 
able to control the versions of software in the hosts that connect, in 
which case they can more aggressively assume support for new features.
Others might want to continue to "support" any old IPv6 implementation, 
hence continue to multicast periodic RAs. (But the sleeping hosts can 
ignore those RAs.)

But note that the current RFC4861 "support" for such hosts without 
resilent-rs is quite unsatisfactory. With MaxRtrAdvInterval at 1800 
seconds that host would sit there with no connectivity for on average 15 
minutes. And there is discussion to raise/remote the upper limit on 
MaxRtrAdvInterval e.g., in section 4.5 in 
draft-yourtchenko-colitti-nd-reduce-multicast-00, thus this would become 
as much as an average of 150 minutes of no service.

The point is that hosts which do not implement resilent-rs will not work 
well on a network with high loss rate for the multicast RS packets; not 
today, not with draft-yourtchenko-colitti-nd-reduce-multicast, and not 
with rs-refresh.

>     What part of the draft leads you to that (incorrect) conclusion? I
>     can definitely clarify that it does not.
>     Nothing in the draft removes part of section 6.2.4 in RFC4861
>     about sending MAX_INITIAL_RTR_ADVERTISEMENTS initial unsolicited RAs.
>
>
It reads as a SHOULD to me in section 6.2.4, and I think I've seen this 
in the IPv6 logo tests.
Even if it had been a MAY, we could have updated it to a SHOULD for 
routers that support rs-refresh.

>         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.
>
>     We discussed draft-garneij-6man-nd-m2m-issues (which points out
>     problems in large cellular networks) in the efficient-nd design
>     team and you were present during those discussions.
>
>
> What part of that problem cannot be solved by upping the maximum value 
> for MaxRtrAdvInterval? The calculations in the draft use a value of 
> 1800, which is 5 times less than the current maximum, and 36 times 
> less than the maximum value that can be stored in the packet.

1800 is the current max.
       MaxRtrAdvInterval
                      The maximum time allowed between sending
                      unsolicited multicast Router Advertisements from
                      the interface, in seconds.  MUST be no less than 4
                      seconds and no greater than 1800 seconds.

As you increase that max you run into the issue above.

Regards,
    Erik

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Mar 2015 00:26:53 +0000 (UTC)

Hi Erik,

Sorry not to get back to you sooner.

----- Original Message -----
From: Erik Nordmark <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>; Lorenzo Colitti <[email-masked]>; Erik Nordmark <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, 6 March 2015, 10:18
Subject: Re: rs-refresh

Mark,

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

/ 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: Erik Nordmark <[email-masked]>
Date: Tue, 17 Mar 2015 09:02:18 -0700

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.

> / 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-…
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 m…

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