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

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.

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.

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", Internet-Draft draft-thomson-webpush-protocol-00, April 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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