Internet DRAFT - draft-ruellan-webpush-low-energy-requirement
draft-ruellan-webpush-low-energy-requirement
WebPush Working Group H. Ruellan
Internet-Draft Canon CRF
Intended status: Informational K. Yasuma
Expires: January 7, 2016 T. Sakai
Canon
July 06, 2015
Low Energy Requirements for WebPush
draft-ruellan-webpush-low-energy-requirement-00
Abstract
Many devices are now connected to the Internet. Receiving
instantaneous notifications from the Web is an appealing but possibly
power-hungry feature. This can be a substantial problem for light
devices with limited battery capacities. WebPush alleviates this
problem by enabling a server to push notifications to the device
instead of having the device regularly poll the server. This is a
first step towards more energy efficient devices, but is still not
sufficient for enabling batteries to last weeks or months without
recharging.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Ruellan, et al. Expires January 7, 2016 [Page 1]
Internet-Draft Low Energy July 2015
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Real-Time Notification . . . . . . . . . . . . . . . . . 2
1.2. Energy Consumption . . . . . . . . . . . . . . . . . . . 2
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Increasing Energy Efficiency with WebPush . . . . . . . . . . 3
3. WebPush Energy Inefficiency . . . . . . . . . . . . . . . . . 3
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
1.1. Real-Time Notification
There is a strong trend of making all devices connected. For a
connected device, real-time notification is an important feature.
Indeed, both major mobile phone platforms offer a notification
service: Apple Push Notification service - APNs - for iOS and Google
Cloud Messaging - GCM - for Android.
WebPush [I-D.thomson-webpush-protocol] is a protocol taking advantage
of HTTP/2 [RFC7540] server push feature for transmitting events or
notifications to a user agent. The Push API
[W3C.WD-push-api-20150427] enables to surface the events received
through WebPush at the web application level. The combination of
these two specifications provides a mechanism for an application
server to push notifications to any web application.
1.2. Energy Consumption
Energy consumption is an important problem for light devices. Users
are keen to have devices that last weeks or months on a single
charge. Not only users are requesting long-lasting battery life, but
standards and regulations for energy-efficient products put always
stricter limits on the energy consumption of devices.
Ruellan, et al. Expires January 7, 2016 [Page 2]
Internet-Draft Low Energy July 2015
In a device, the screen, CPU, and network access - usually through a
wireless network - consume much of the available energy available.
In particular, real-time notification consumes both CPU and wireless
communication. These consumptions should be reduced as much as
possible for preserving battery life.
1.3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Increasing Energy Efficiency with WebPush
The legacy mechanism for receiving notifications from a web server is
to use polling. However, polling has a main drawback: it requires to
send frequent poll requests to check whether a new notification is
available on the server side. Sending a request consumes CPU and
bandwidth, which translates to energy consumption.
In addition, polling is rather inefficient: most of the time the
requests sent to the server will return no new notification. This
inefficiency can be reduced by increasing the interval between poll
requests, but this is to the detriment of latency: a new notification
will only be received after the next poll request occurs.
Pushing is much more efficient: all the messages sent by the server
contain one or more notifications. As such, no energy is wasted for
unnecessary messages, which can greatly reduce the energy consumption
related to notifications.
3. WebPush Energy Inefficiency
WebPush is improving the energy efficiency related to transmitting
notifications from a web server to a device. However, there are
still some areas that could be improved.
WebPush is relying on HTTP/2, which itself relies on TCP. To be able
to send a notification, the WebPush protocol needs an open HTTP/2
connection, which in turns needs an open TCP connection.
Maintaining the TCP connection open requires to send some _Keep-
Alive_ messages (for example to prevent a NAT, or a Firewall from
dropping the connection). These messages, while not useful for
transmitting notifications per-se still require using the device's
wireless connection.
Ruellan, et al. Expires January 7, 2016 [Page 3]
Internet-Draft Low Energy July 2015
Studies have found that the frequency of Keep-Alive messages required
on Cellular Network can be quite high. In [Wang2011], a study of
cellular ISPs found that 15% of them had a timeout for idle TCP
connection of less than 10 mn. The authors estimated that this 10 mn
timeout increased the energy consumption by 10%. A few ISPs had even
shorter timeout durations, further increasing the energy consumption.
In addition, some push server could use HTTP/2 PING frames to check
whether the underlying TCP connection is alive. A high frequency of
PING frames would also impact the energy efficiency of the
transmission of notifications.
Another problem is that, if no specific care is taken, two
consecutive notifications could be sent separately, even if they are
separated only by a short time-interval. Sending them jointly would
be more efficient energy-wise. They could either be transmitted
inside the same TCP segment, or at least during the same active
period of the device wireless sub-system. Such a grouping would be
similar to TCP Nagle Algorithm: the push server would slightly delay
the transmission of a notification to have the possibility of
grouping it with any further notification incoming shortly after.
4. Conclusion
WebPush is a clear improvement towards energy efficient notification
systems for connected devices. Further improving the energy
efficiency of this technology would widen its applicability. A first
step could be to identify and evaluate the problems. Work could then
be started on providing solutions to the identified problems through
guidelines, profiles and/or new standards.
5. Security Considerations
TBD.
6. References
6.1. Normative References
[I-D.thomson-webpush-protocol]
Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
Delivery Using HTTP Push", draft-thomson-webpush-
protocol-00 (work in progress), April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Ruellan, et al. Expires January 7, 2016 [Page 4]
Internet-Draft Low Energy July 2015
6.2. Informative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol Version 2 (HTTP/2)", RFC 7540, May 2015.
[W3C.WD-push-api-20150427]
Sullivan, B., Fullea, E., and M. Ouwerkerk, "Push API",
World Wide Web Consortium WD WD-push-api-20150427, April
2015, <http://www.w3.org/TR/2015/WD-push-api-20150427>.
[Wang2011]
Wang, Z., Qian, Z., Xu, Q., Mao, Z., and M. Zhang, "An
Untold Story of Middleboxes in Cellular Networks", SIGCOMM
'11 , 2011.
Authors' Addresses
Herve Ruellan
Canon CRF
Email: herve.ruellan@crf.canon.fr
Kensuke Yasuma
Canon
Email: nws-ky@list.canon.co.jp
Tomoya Sakai
Canon
Email: nws-ts@list.canon.co.jp
Ruellan, et al. Expires January 7, 2016 [Page 5]
