Subject: Comments on the analysis in draft-garneij-6man-nd-m2m-issues-00

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Apr 2015 11:28:14 +0900

Hi,

in the context of looking at the RS refresh draft, I looked at the
assertion in draft-garneij-6man-nd-m2m-issues-00 , which is cited as one of
the use cases. IIUC the issue boils down to: in a network with a large
number of completely silent devices, the periodic RA, which is sent on
average every 1575 seconds, ends up being the dominating factor in paging
channel usage.

I think there is an easy way to fix this: raise the maximum RA lifetime and
the maximum RA interval as proposed by draft-krishnan-6man-maxra-01. That
will lower the paging cost by a factor of 12x (21845 / 1800). If a that is
not sufficient, then the cost can further be lowered by ensuring that the
entity that deals with the mobile node's IP traffic (in 3GPP networks, the
GGSN or the PGW) sends RAs opportunistically, bundling them with any other
packets that it needs to send the device. If the device receives at least
one packet in every 21845-second interval, then the extra paging cost goes
down to zero. Even if the device never receives *any* packets (though that
seems really unlikely: how does it know if it is reporting correctly, and
that its controller is still receiving its traffic? The internet does not
have zero loss), the RAs can still be sent opportunistically when the
device *sends* a packet. The PGW will see the device send the packet and
can opportunistically send the RA, knowing that the device will be in a
high power state for a little while after sending the packet.

Also, I think we should carefully consider the impact of the problem. This
is very much a contrived worst-case scenario. If the network is a general
purpose network, such as a commercial LTE network, the paging cost will in
general be much higher, because that network also provides service to
devices such as phones and tables that are orders of magnitude more chatty
(due to users wanting to use the connection they paid for). So in general,
commercial networks will not be optimized for this sort of usage. It's true
that it's possible to optimize for M2M devices, and ensure that those
devices use as few resources as possible, but in a general-purpose network,
there's likely no point in doing that because the chattier devices are
causing most of the cost anyway (Amdahl's law).

Also note that the impact is on *paging channel* usage, not *power* usage.
I'm not an expert, but AIUI in current radio technologies such as LTE, for
a node that only sends a short burst of data every 12 hours, power is
likely dominated by the cost of staying attached to the network, listening
to the paging group, dealing with location area updates, etc. rather than
sending the packets. If you care about power, the right strategy is to
disconnect from the network completely, and only reconnect when you have
something to transmit.

Cheers,
Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Fri, 24 Apr 2015 11:48:16 +0900

Agreed.

Three additional points:

    [1] draft-krishnan-6man-maxra-01, Section 3, paragraph 1: +1.

    [2] draft-krishnan-6man-maxra-01, Section 3, paragraph 2: I think
it should be struck from that document and not be construed as
recommended here.

    [3] I would support a document that describes "opportunistic RAs".  :-)

On Fri, Apr 24, 2015 at 11:28 AM, Lorenzo Colitti <[email-masked]> wrote:
> Hi,
>
> in the context of looking at the RS refresh draft, I looked at the assertion
> in draft-garneij-6man-nd-m2m-issues-00 , which is cited as one of the use
> cases. IIUC the issue boils down to: in a network with a large number of
> completely silent devices, the periodic RA, which is sent on average every
> 1575 seconds, ends up being the dominating factor in paging channel usage.
>
> have zero loss), the RAs can still be sent opportunistically when the device
> *sends* a packet. The PGW will see the device send the packet and can
> opportunistically send the RA, knowing that the device will be in a high
> power state for a little while after sending the packet.
>
> I'm not an expert, but AIUI in current radio technologies such as LTE, for a
> node that only sends a short burst of data every 12 hours, power is likely
> dominated by the cost of staying attached to the network, listening to the
> paging group, dealing with location area updates, etc. rather than sending
> the packets. If you care about power, the right strategy is to disconnect
> from the network completely, and only reconnect when you have something to
> transmit.
>
> Cheers,
> Lorenzo
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Apr 2015 03:12:12 +0000

Hi Lorenzo,
   Thanks for your comments. Please find responses inline.

On 04/23/2015 10:28 PM, Lorenzo Colitti wrote:
> assertion in draft-garneij-6man-nd-m2m-issues-00 , which is cited as one
> of the use cases. IIUC the issue boils down to: in a network with a
> large number of completely silent devices, the periodic RA, which is
> sent on average every 1575 seconds, ends up being the dominating factor
> in paging channel usage.
>
> I think there is an easy way to fix this: raise the maximum RA lifetime
> and the maximum RA interval as proposed by draft-krishnan-6man-maxra-01.

Sounds good.

> That will lower the paging cost by a factor of 12x (21845 / 1800). If a
> that is not sufficient, then the cost can further be lowered by ensuring
> that the entity that deals with the mobile node's IP traffic (in 3GPP
> networks, the GGSN or the PGW) sends RAs opportunistically, bundling
> them with any other packets that it needs to send the device. If the
> device receives at least one packet in every 21845-second interval, then
> the extra paging cost goes down to zero. Even if the device never
> receives *any* packets (though that seems really unlikely: how does it
> know if it is reporting correctly, and that its controller is still
> receiving its traffic? The internet does not have zero loss), the RAs
> can still be sent opportunistically when the device *sends* a packet.
> The PGW will see the device send the packet and can opportunistically
> send the RA, knowing that the device will be in a high power state for a
> little while after sending the packet.
>
> Also, I think we should carefully consider the impact of the problem.
> This is very much a contrived worst-case scenario. If the network is a
> general purpose network, such as a commercial LTE network, the paging
> cost will in general be much higher, because that network also provides
> service to devices such as phones and tables that are orders of
> magnitude more chatty (due to users wanting to use the connection they
> paid for). So in general, commercial networks will not be optimized for
> this sort of usage. It's true that it's possible to optimize for M2M
> devices, and ensure that those devices use as few resources as possible,
> but in a general-purpose network, there's likely no point in doing that
> because the chattier devices are causing most of the cost anyway
> (Amdahl's law).
>
> Also note that the impact is on *paging channel* usage, not *power*
> usage. I'm not an expert, but AIUI in current radio technologies such as
> LTE, for a node that only sends a short burst of data every 12 hours,
> power is likely dominated by the cost of staying attached to the
> network, listening to the paging group, dealing with location area
> updates, etc. rather than sending the packets. If you care about power,
> the right strategy is to disconnect from the network completely, and
> only reconnect when you have something to transmit.

You are only considering the effect on the UE and not on the network 
itself. The network will be impacted either way. Frequent attaches and 
detaches also increase the signaling load on the network. And the amount 
of signaling needed to attach probably does not help with the power 
efficiency of the UE either (This needs to be addressed anyway for M2M 
and is not an IETF problem :-)).

Thanks
Suresh

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Apr 2015 12:16:41 +0900

> and is not an IETF problem :-)).

Right, it will be impacted either way. You're trading off location update
cost vs. attach cost vs. paging channel cost. However, I think it's
important to note that sending RAs opportunistically will remove most of
the extra cost.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Apr 2015 03:19:06 +0000

Hi Erik,

Sounds good.

> it should be struck from that document and not be construed as

I would like to understand your reasons a bit. Is this because you think 
multicast RAs are absolutely needed or because sending RAs only when 
solicited is bad?

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Apr 2015 03:27:19 +0000

Hi Lorenzo,

On 04/27/2015 11:17 PM, Lorenzo Colitti wrote:
> On Tue, Apr 28, 2015 at 12:12 PM, Suresh Krishnan
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Right, it will be impacted either way. You're trading off location
> update cost vs. attach cost vs. paging channel cost. However, I think
> it's important to note that sending RAs opportunistically will remove
> most of the extra cost.

Yep. I will try to run some numbers for the attach-when-needed scenario 
as well to see what the tradeoffs are. I need to do a bit of literature 
review to figure out if the network nodes sending the RAs are aware of 
the duty cycles of the M2M devices (maybe Fredrik or Samita can chime in 
right away).

Thanks
Suresh

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Apr 2015 12:29:48 +0900

> the duty cycles of the M2M devices (maybe Fredrik or Samita can chime in

They don't need to be though, right? As the first-hop router of every node
in the network, they know when those nodes emit packets, and when they
receive packets. They can then ensure that they send packets in time for
those nodes to receive them before they go back to sleep.

---

From: Erik Kline <[email-masked]>
Date: Tue, 28 Apr 2015 12:52:46 +0900

> multicast RAs are absolutely needed or because sending RAs only when

Sending unicast RAs whenever solicited: +1.

Sending opportunistic unicast RAs whenever the router has other
packets to deliver anyway: +1.  (Yes, this is not currently documented
anywhere.)

Overall I'm concerned about the propensity for everything to be
increasingly static.  Soon we'll hear: a billion clients polling via
unicast RS is putting too much load on the infrastructure to generate
the correct RAs.  And then we'll copy'n'paste DHCPv6 Squelch into RS
Squelch--either that or infinite RAs.

I don't want us to lose the *operational* ability to reconfigure,
despite the fact the protocol will continue to nominally support it.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Apr 2015 08:35:21 -0700

On 4/27/15 8:52 PM, Erik Kline wrote:

> increasingly static.
Erik,

I don't understand how sending a RS to get an RA results in more static 
configuration than what RFC 4861 has.
RFC 4861 allows for prefix lifetimes to be infinite (which FWIW I think 
was a mistake). Whether the information is pushed or pulled has no 
impact on NUD being able to switch from an unreachable router to a 
reachable one.

You've pointed out that in rs-refresh we shouldn't allow an infinite 
refresh time, and I think that would be an improvement over RFC 4861. 
But even without that fix I don't see how rs-refresh would be more 
static than 4861.

What am I missing?

>    Soon we'll hear: a billion clients polling via
Can you give an example where rs-refresh would not be able to 
reconfigure the hosts?
Are you assuming that implementations for some reason are more likely to 
have bugs relating to rs-refresh then they do for 4861? Or some other 
unstated assumptions?

Thanks,
    Erik