[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                      G. Montenegro
Internet-Draft                                                 Microsoft
Intended status: Informational                               S. Cespedes
Expires: January 9, 2017                            Universidad de Chile
                                                               S. Loreto
                                                              R. Simpson
                                                        General Electric
                                                            July 8, 2016

                H2oT: HTTP/2 for the Internet of Things


   This document makes the case for HTTP/2 for IoT.

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 9, 2017.

Copyright Notice

   Copyright (c) 2016 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

Montenegro, et al.       Expires January 9, 2017                [Page 1]

Internet-Draft                    H2oT                         July 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Application Transport Alternatives and their Strengths  . . .   4
     2.1.  HTTP/1.1  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  MQTT  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  CoAP  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Protocols Comparison  . . . . . . . . . . . . . . . . . .   8
   3.  Importance of Protocol Reuse  . . . . . . . . . . . . . . . .   8
   4.  HTTP/2 in IoT . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Profile of HTTP/2 for IoT . . . . . . . . . . . . . . . . . .  11
   6.  Negotiation of HTTP/2 for IoT . . . . . . . . . . . . . . . .  12
   7.  Gateway and Proxying Issues . . . . . . . . . . . . . . . . .  12
   8.  Implementation Considerations . . . . . . . . . . . . . . . .  13
   9.  Experimentation and Performance . . . . . . . . . . . . . . .  13
     9.1.  GET Example . . . . . . . . . . . . . . . . . . . . . . .  14
       9.1.1.  HTTP/1.1  . . . . . . . . . . . . . . . . . . . . . .  14
       9.1.2.  HTTP/2  . . . . . . . . . . . . . . . . . . . . . . .  15
       9.1.3.  Comparison  . . . . . . . . . . . . . . . . . . . . .  16
   10. HTTP/2 over UDP - QUIC  . . . . . . . . . . . . . . . . . . .  16
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     14.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   When the IETF started work on the Internet-of-Things ("IoT") with the
   6lowpan WG, it was clear that in addition to the lower-layer
   adaptation work for IPv6, much work elsewhere in the stack was
   necessary.  (In this document, the "things" in "IoT" are nodes that
   are constrained in some manner--e.g., cpu, memory, power--such that
   direct use of unmodified mainstream protocols is challenging.)  Once
   the IPv6 adaptation was understood, the next question was what
   protocols to use above IP(v6) for different functions and at
   different layers to have a complete stack.  That question may not
   have a single answer that is always best for all scenarios and use
   cases.  There are many such use cases, in accordance with the fact
   that IoT means too many things.

   Accordingly, the IoT landscape includes a proliferation of options
   for any particular functionality (transport, encoding, security

Montenegro, et al.       Expires January 9, 2017                [Page 2]

Internet-Draft                    H2oT                         July 2016

   suites, authentication/authorization, etc).  Different vendors and
   standards organizations (or fora) offer IoT solutions by grouping
   these different components into separate stacks.  Even if the
   components have the same name or originate in the same original
   standard (or even in the same code base), each organization adapts it
   ever so slightly to their own goals, often rendering the resultant
   components non-interoperable.  Many of these components are being
   created expressly for IoT (within the IETF and elsewhere) under the
   assumption that the mainstream options could not possibly be usable
   for IoT scenarios.  This results in multiple disparate networking and
   software stacks.  Given the incipient state of IoT, for the
   foreseeable future multiple competing stacks will continue to exist
   at least in gateways and cloud elements.  The additional complexity
   to IoT amplifies the attack surface.  Nevertheless, properly
   configured and implemented, mainstream options may not just be
   workable, but may even be the best option at least in some scenarios.

   The appearance of one-off stacks (as opposed to a properly configured
   and adapted mainstream stack) is reminiscent of WAP 1.x, a complete
   vertical stack offered for phones as they were starting to access the
   Internet (albeit from within a walled garden) in the late 90's.  At
   that time the IETF and the W3C started efforts to develop the
   mainstream alternatives.  As a result, today no phone uses WAP.
   Instead, phone stacks are mainstream TCP/IP protocols (properly
   configured and adapted, of course).  In contrast, today in IoT we see
   not just one non-mainstream stack, but several (as if we had not just
   WAP, but WAP1, WAP2, WAP3, etc.).  And we may have to live with them
   for some time, but it is essential to ponder what the mainstream
   stack might look like if we are to eventually reap the benefits of a
   true Internet of Things instead of a not-quite-but-kinda-close-to-

   HTTP/2 [RFC7540][RFC7541] is now widely available as a transport
   option.  Moreover, the ongoing effort to layer HTTP/2 over UDP (i.e.,
   over QUIC) adds a useful capability for IoT scenarios.  We show the
   current suitability of HTTP/2 for IoT scenarios and examine possible

   Let's look at some application communication patterns to establish
   some common language (see also section 2 of [RFC7452] for a related

   node to node:  A constrained node engages in direct communication
      with another constrained node.

   node to gateway:  A constrained node and a gateway node engage in
      direct communication.  A gateway node is directly on both a
      constrained network (e.g., a lowpan) and on a non-constrained

Montenegro, et al.       Expires January 9, 2017                [Page 3]

Internet-Draft                    H2oT                         July 2016

      network (a normal network using mainstream stack implementations,
      typically connected to the Internet).

   gateway to cloud:  A gateway node (see above) engages in
      communication with unconstrained networks, typically a cloud
      service on the Internet.

   node to cloud:  A node on a constrained network engages in direct
      communcation with unconstrained networks, typically a cloud
      service on the Internet.

   In the above, a "node" may, in fact, be multiple nodes when engaging
   in group communication.  Group communications (e.g., via multicast)
   are commonly used for discovery or routing (see also Section 2.3).

   We can further categorize the above communication patterns into two
   basic types of networking exchanges:

   Constrained network scenario:  A constrained network scenario
      includes node to node and node to gateway exchanges.  Group
      communications are another typical aspect of these constrained

   Internet scenario:  An Internet scenario includes gateway to cloud
      and node to cloud exchanges.

   This document makes the case for HTTP/2 as the most general protocol
   of choice for Internet of Things applications.  HTTP/2 is most at
   home in Internet scenarios and is also suitable for at least some
   Constrained network scenarios.

2.  Application Transport Alternatives and their Strengths

   A recent survey by the Eclipse IoT working group queried IoT
   developers about the protocols and technologies they are using and
   planning to use [Eclipse_survey].  Some of the currently used
   application transport protocols (above the link layer) for IoT
   applications are as follows:

   o  HTTP/1.1 (61% of developers)

   o  MQTT (52% of developers)

   o  CoAP (21% of developers)

   o  HTTP/2 (19% of developers)

   o  Others: In-house, AMQP and XMPP (43% of developers)

Montenegro, et al.       Expires January 9, 2017                [Page 4]

Internet-Draft                    H2oT                         July 2016

   It is interesting to note that in the same survey done in 2015,
   HTTP/2 was not even present, whereas it is now at 19% (the other
   protocols are mostly unchanged).  No doubt it is being used in
   scenarios where there are no major constraints (precisely where
   HTTP/1.x is also being used).  Optimizing it for IoT can further
   promote its use.  The sections below provide some more details on
   top-of-the-list protocols other than HTTP/2.

2.1.  HTTP/1.1

   HTTP/1.1 is a text-based protocol, and is widely successful as it is
   the basis not just for the web, but for much non-web traffic in the
   internet today.  Most (but not all) of the instances of HTTP today
   implement version 1.1 as specified in RFC2616 [RFC2616].  Since its
   publication back in 1999 it has evolved organically, producing
   countless variations and exceptions to its rules.  Modern browser and
   server implementations have very complex and convoluted code to deal
   with parsing and handling the many nuances of the protocol.  Because
   of all this confusion, the HTTPbis working group set out to clarify
   the existing specifications, and after a multi-year effort to clarify
   its many sources of confusion, it has published a cleaner
   specification in RFCs 7230-7235 [RFC7230] [RFC7231] [RFC7232]
   [RFC7233] [RFC7234] [RFC7235].  In spite of this, the protocol still
   has a plethora of legacy issues and remains too verbose.

   HTTP/1.1 is very clearly a mismatch for the constrained devices and
   networks that characterize IoT.  Despite its shortcomings, it is the
   most popular protocol for IoT applications (61% per the
   aforementioned survey, although the survey does not clarify if this
   is for Internet or constrained network scenarios).  Why would such an
   ill-suited protocol be clearly the most popular for IoT applications?
   It is by far the most commonly known protocol.  It has many
   implementations (many in open source), with massive support in all
   platforms, tools and APIs.  It is easy to find know-how and support.
   In short, it has the power and convenience that comes with being a
   mainstream protocol.

   Another major advantage is that it is the protocol that has the best
   chance of traversing firewalls and middle boxes in the internet due
   to its use of port 80 when in the clear, and, especially, its use of
   port 443 when over TLS.  This is a primary concern in Internet

2.2.  MQTT

   MQ Telemetry Transport (MQTT) is a publish/subscribe messaging
   protocol that runs on top of TCP.  It was created by IBM.  Version
   3.1.1 is available as an OASIS standard [mqtt_oasis] and as an ISO

Montenegro, et al.       Expires January 9, 2017                [Page 5]

Internet-Draft                    H2oT                         July 2016

   publication [mqtt_iso].  It is popular in the Internet scenario (node
   to cloud, gateway to cloud) and it aims to connect embedded devices
   and networks with applications and middleware.  It is a compact,
   binary protocol, and is very popular in certain application domains.
   It has been known as a protocol suitable to be used in resource
   constrained devices and unreliable networks.

   It is the second most popular protocol in the survey (behind
   HTTP/1.1) with 52% of developers using it.  In the internet scenario,
   however, TLS is probably required.  This additional TLS overhead
   renders all protocols slightly larger, so, e.g., MQTT loses some
   relative size advantage.

   The MQTT protocol requires an underlying transport that provides an
   ordered, lossless, stream of bytes from the Client to Server and
   Server to Client.  It cannot be used over UDP.  There is an
   alternative (and not standardized) variant called MQTT-SN (previously
   called MQTT-S) which can use UDP, Zigbee or other datagram
   transports, but this is a substantially different protocol which has
   been tailored to meet the needs of small, battery-powered sensors
   connected by wireless sensor networks (WSNs), and relies upon a MQTT-
   SN Gateway or forwarder for external communications.

   MQTT is closely tied to PUBLISH/SUBSCRIBE operations and this is the
   only mode of message transfer.  This means that MQTT cannot be used
   for "node to node" communications because a server is required (the
   server forwards messages between publishers and subscribers, manages
   subscriptions, and performs user authorization functions.)  The
   exclusive use of publish/subscribe operations can complicate some IoT
   operations, such as request-response traffic, and transferring large
   payloads (e.g. firmware updates).  It is sometimes desirable to use a
   different protocol (like HTTP) for transferring large payloads, even
   though MQTT supports a maximum per-message payload size of 256 MiB.
   The OASIS MQTT-TC is considering proposals involving changes in
   handling request-response traffic and large message transfers.

   MQTT is deployed over TCP (port 8833 when over TLS, port 1883 without
   TLS).  Even when using TLS, it has the well-known firewall traversal
   issues common to any protocol not over port 443.

2.3.  CoAP

   CoAP is a compact, binary, UDP-based protocol based on RESTful
   principles and closely patterned after HTTP.  It has been designed to
   be used in constrained devices and constrained networks.  The
   protocol specification has been published [RFC7252], although
   additional functionalities such as congestion control, block-wise

Montenegro, et al.       Expires January 9, 2017                [Page 6]

Internet-Draft                    H2oT                         July 2016

   transfer, TCP and TLS transfer and HTTP mapping are still being

   The protocol meets IoT requirements through the modification of some
   HTTP functionalities to achieve low-power consumption and operation
   over lossy links.  To avoid undesirable packet fragmentation the CoAP
   specification provides an upper bound to the message size, dictating
   that a CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP datagram:

      If the Path MTU is not known for a destination, an IP MTU of 1280
      bytes SHOULD be assumed; if nothing is known about the size of the
      headers, good upper bounds are 1152 bytes for the message size and
      1024 bytes for the payload size.

   CoAP interaction with HTTP must traverse a proxy, with the
   concomitant issues of breaking end-to-end security (Section 7), but
   at least the common REST architecture makes it easier.

   CoAP works on port 5683 and offers optional reliable delivery (thru a
   retransmission mechanism), support for unicast and multicast, and
   asynchronous message exchange.  Multicast (see Section 1 is typically
   used by IoT SDO's for routing and discovery.  A common use of
   multicast within CoAP is for discovery, something addressed in
   mainstream (and even some IoT) scenarios via mDNS [RFC6762] and DNS-
   SD [RFC6763].  More general uses of multicast within CoAP (and, in
   general, at the application transport, e.g., to address group
   communication for IoT), introduces complexity for security, IPv6
   scoping, wireless reliability, etc.

   A typical CoAP message can be between 10 and 20 bytes.

   It is the third most popular protocol in the survey with a 21%
   preference.  Nevertheless, since CoAP is UDP-based, in the Internet
   scenario it also suffers from firewall traversal issues, verbosity
   (as compared to TCP) to maintain state in NAT boxes and lack of
   integration with existing enterprise infrastructures.  There is
   ongoing work to specify the use of CoAP over TCP as well as CoAP over
   TLS, in an attempt to overcome issues with middleboxes and improve
   its applicability to Internet scenarios.

   As noted above, there is much ongoing work on CoAP, and much of it
   seeks to define a transport on top of UDP.  This is a very complex
   task not to be underestimated.  QUIC is also embarking on this task,
   but it appears to be benefitting from many more resources within the
   networking community at large.

Montenegro, et al.       Expires January 9, 2017                [Page 7]

Internet-Draft                    H2oT                         July 2016

2.4.  Protocols Comparison

   The aformentioned protocols have been compared in both experimental
   and emulated environments [IEEE_survey].  Previous reports show that
   performance is highly dependent on the network conditions: in good
   link conditions with low packet loss, MQTT delivers packets with
   lower delay than CoAP, but CoAP outperforms when high packet losses
   are present; in terms of packet sizes, if packet loss is under 25%
   and messages are of a small size, CoAP demonstrates a better link
   usage than MQTT.  However, other experiments report a better
   performance of MQTT in high traffic/high packet loss scenarios
   [IoT_analysis].  CoAP has also been compared to HTTP/1.1.  In terms
   of power consumption and response time, naturally CoAP behaves better
   than HTTP/1.1 thanks to the reduced packet sizes.

   Coexistence among the protocols has also been tested with varied
   network configurations.  For the most part, interaction of CoAP with
   HTTP has been studied [Web_things], demonstrating successful exchange
   when there is a CoAP server running on a constrained node and the
   HTTP client is requesting resources from it, or when there is a CoAP
   client requesting resources from an HTTP server.  In both cases a
   proxy is necessary to enable translation between the protocols.
   Another network configuration with a CoAP client - CoAP proxy - CoAP
   server has been compared to the CoAP client - CoAP/HTTP proxy - HTTP
   server configuration, in which case the response times of the only-
   CoAP configuration resulted to be lower even when the number of
   concurrent requests increases [CoAP_integration].

   To date, no reports have been found comparing MQTT or CoAP to HTTP/2.

3.  Importance of Protocol Reuse

   These protocols often do not exist in a vacuum.  Typically, they are
   mandated as part of a given stack specified by any of several IoT
   consortia (e.g., OCF, AllSeen Alliance/AllJoyn, Thread Group).  We
   know that these multiple IoT protocols (and stacks) provide very
   useful sources of information for prying eyes (See "US intelligence
   chief says we might use the IoT to spy on you" at
   http://www.wired.com/2012/03/petraeus-tv-remote/).  Security and
   privacy issues are exacerbated because:

   o  IoT is the worst of all security worlds: (1) constraints push
      devices into taking shortcuts and (2) there is less physical
      security with such devices (after installation they are typically
      reachable by unfriendly hands).

   o  Each of these protocols is an island with its own security
      measures (or lack thereof) and very limited review.

Montenegro, et al.       Expires January 9, 2017                [Page 8]

Internet-Draft                    H2oT                         July 2016

   The previous two points can be summarized as follows:

   A security and privacy environment even more challenging than usual:

      This is receiving much attention from the research and
      standardization communities.  It is the sort of challenge that
      stimulates researchers into high gear.  It is a daunting problem
      for sure, but at least it is on the radar of folks and consortia
      working on IoT.  Nevertheless, many issues will arise because of
      this (e.g., discovery of serious flaws in IoT devices like locks
      is a common occurrence).

   Many different protocol stacks at play:  This is a much more
      worrisome issue if one considers that a vast majority of issues
      arising with security have less to do with cryptography (the first
      point above) and more to do with software engineering, and silly
      bugs.  Each stack added creates more attack surface.  At the same
      time, each one of these stacks gather less attention and scrutiny
      than software used for mainstream scenarios (such as the web).  We
      have seen no shortage of issues on OpenSSL and similar heavily-
      used software.  We can expect much worse from stacks that are not
      nearly as well exercised nor examined.  And if we have not one,
      but several of these stacks untested by millions of eyeballs, we
      are inviting disaster.

   A recent Harvard report on the state of surveillance and erosion of
   privacy [Going_Dark] concludes among its findings that the projected
   substantial growth of IoT will drastically change surveillance
   (surveillance is not merely limited to government agencies of
   course), and that the fragmentation of ecosystems hinders the
   deployment of countermeasures (e.g., end-to-end encryption) as that
   requires more coordination and standardization than currently
   available.  This not only gives rise to rogue surveillance sites such
   as Shodan (https://www.shodan.io/), but also represents a great
   opportunity for government agencies' surveillance needs [Clapper].

   Furthermore, multiple stacks defeat one of the main benefits of the
   "I" in IoT: interoperability.  Also, reusing mainstream protocols
   affords the benefits of using better-known technology, with easier
   access to reference implementations (including open source), people
   with the required skills and experience, training, etc.  These are
   basically the same arguments that were used originally to justify the
   use of IP-based networking over custom-built stacks.  The message was
   heard loud and clear but for the most part it was applied to only a
   limited set of components (e.g., IP, UDP, DTLS).  Other components
   are still being custom built (albeit, on top of IP).

Montenegro, et al.       Expires January 9, 2017                [Page 9]

Internet-Draft                    H2oT                         July 2016

4.  HTTP/2 in IoT

   As noted above, for the foreseeable future the IoT landscape requires
   several stacks.  Thinking about a canonical stack based on mainstream
   protocols is not an exercise in the delusion that one single stack
   will be enough.  Rather, it is an attempt to define an option that
   can serve IoT better into the future, and one that can be recommended
   whenever there is a choice (often there isn't one).

   The goals in pursuing a canonical stack are the following:

   o  Maximize Standards-based Elements across technologies and IoT

   o  Reduce IoT protocol idiosyncrasies and specificity

   o  Reduce the number of "translators" needed in an IoT hub

   To arrive at a canonical stack the mainstream standards-based stack
   must be properly profiled and optimized.  This requires optimizing
   aspects such as:

   o  Authentication and Authorization framework by adapting OAUTH
      instead of inventing a new system [I-D.ietf-ace-oauth-authz].

   o  Device Management and Object Model/Descriptions (currently being

   o  Discovery via mDNS [RFC6762] and DNS-SD [RFC6763] perhaps
      augmented with IoT considerations, e.g.,
      [I-D.aggarwal-dnssd-optimize-query].  Another option to
      investigate is that of HTTP/2 over multicast.  Whereas there have
      been some forays into HTTP over multicast, it is not nearly as
      well deployed, implemented and understood as mDNS.

   o  Application Transport based on HTTP/2.

   This document deals only with the application layer transport based
   on HTTP/2.

   HTTP/2 is a good match for IoT for several reasons:

   o  Binary and Compact (9 byte header)

   o  Header Compression [RFC7541]

   o  Traversal past firewalls/middle boxes via TLS over port 443

Montenegro, et al.       Expires January 9, 2017               [Page 10]

Internet-Draft                    H2oT                         July 2016

   o  Support of RESTful model in major development frameworks

   o  Know-how widely available

5.  Profile of HTTP/2 for IoT

   HTTP/2 has many negotiable settings that can improve its performance
   for IoT applications by reducing bandwidth, codespace, and RAM
   requirements.  Specifically, the following settings and values have
   been found to be useful in IoT applications:

   o  SETTINGS_HEADER_TABLE_SIZE: this setting allows hosts to limit the
      size of the header compression table used for decoding, reducing
      required RAM, but potentially increasing bandwidth requirements.
      Initial value per HTTP/2 is 4096.  IoT scenarios might benefit
      from changing this to a smaller value (e.g., 512), however, to
      avoid increased bandwidth usage, IoT scenarios should judiciously
      use HTTP headers and the dynamic header table [RFC7541].

   o  SETTINGS_ENABLE_PUSH: This setting allows clients to enable or
      disable server push.  This functionality may not be required in
      some IoT applications.  The initial value per HTTP/2 is 1.

   o  SETTINGS_MAX_CONCURRENT_STREAMS: this setting allows a sender to
      limit the number of simultaneous streams that a receiver can
      create for a connection.  HTTP/2 recommends this value be no
      smaller than 100.  IoT scenarios may wish to limit this to a much
      smaller number, such as 2 or 3.

   o  SETTINGS_INITIAL_WINDOW_SIZE: this setting allows hosts to limit
      the flow control window, potentially reducing buffer requirements
      at the expense of potentially underutilized bandwidth-delay
      products.  Per HTTP/2 the initial value is 2^16-1 (65,535) octets.
      IoT scenarios may wish to limit this to smaller values in
      accordance with the node's constraints (e.g., a few kilo-octets).

   o  SETTINGS_MAX_FRAME_SIZE: this setting allows hosts to specify the
      largest frame size they are willing to receive.  Per HTTP/2 the
      initial value is 2^14 (16,384) octets.  Somewhat
      counterintuitively, IoT hosts may wish to leave this value large
      and rely on flow control to avoid unnecessary framing overhead.

   o  SETTINGS_MAX_HEADER_LIST_SIZE: this setting allows hosts to limit
      the maximum size of the header list they are willing to receive.
      Per HTTP/2 the initial value of this setting is unlimited.  IoT
      scenarios may wish to limit this to smaller values in accordance
      with the node's constraints (e.g., a few kilo-octets).

Montenegro, et al.       Expires January 9, 2017               [Page 11]

Internet-Draft                    H2oT                         July 2016

6.  Negotiation of HTTP/2 for IoT

   For Constrained and Internet scenarios, it is assumed that HTTP/2
   runs over TLS.  Accordingly, the ALPN negotiation in section 3.3 of
   [RFC7540] applies.  As seen above, an IoT scenario may wish to depart
   from the default SETTINGS.  To do so, the usual SETTINGS negotiation
   applies.  In this case, the initial SETTINGS negotiation setup is
   based on the first message exchange initiated by the client.  This is
   simpler than general HTTP/2 case: not having an in-the-clear Upgrade
   path means the client is always in control of first HTTP/2 message,
   including any SETTINGS changes it may wish.

   Additionally, the use of "prior knowledge" per section 3.4 of
   [RFC7540] is likely to also work particularly well in IoT scenarios
   in which a client and its web service are likely to be closely
   matched.  In such scenarios, prior knowledge may allow for SETTINGS
   to be set in accordance with some shared state implied by the the
   prior knowledge.  In such cases, SETTINGS negotiation may not be
   necessary in order to depart from the defaults as defined by HTTP/2.

7.  Gateway and Proxying Issues

   The proliferation of application and security protocols in the IoT
   has produced the deployments of islands of IoT devices, each using
   one of the several protocols available.  However, usually an IoT
   deployment needs to communicate to another one, or at least needs to
   communicate with the Web, both because they have to upload data to
   the Cloud or because usually they are controlled by a Web

   In such cases, communication is facilitated by a cross-protocol proxy
   or a gateway translating from one protocol syntax and semantic into
   another one.  However, the presence of Cross-Protocol or Application
   gateways has at least two main drawbacks that need to be analyzed and
   addressed carefully.

   o  while the translation may be trivial for the basic scenarios,
      there are a lot of cases where the translation can lead to
      information loss or an incompatibility due to the different way
      different proxies make the translation.

   o  The presence of such devices may also become a critical point for

Montenegro, et al.       Expires January 9, 2017               [Page 12]

Internet-Draft                    H2oT                         July 2016

8.  Implementation Considerations

   This section assumes HTTP/2 over TCP.

   In addition to underlying stack considerations with respect to IPv4,
   IPv6, TCP, and TLS, there are implementation considerations for
   HTTP/2 for IoT.

   A primary consideration is the number of allowed simultaneous HTTP/2
   connections.  As each connection has associated overhead, as well as
   overhead for each stream, constrained hosts may wish to limit their
   number of simultaneous connections.  However, implementers should
   consider that some popular browsers require more than one connection
   to operate.

   In addition to minimizing the number of simultaneous connections,
   hosts should consider leaving connections open if there is a
   possibility of further communication with the remote peer.  HTTP/2
   contains mechanisms such as PING to periodically check idle
   connections.  Leaving established connections open when there is a
   possibility of future communication allows connection establishment
   overhead (and potentially TLS session establishment overhead) to be

   Should TLS be used, implementers may wish to consider utilizing
   hardware-based encryption to further reduce codespace and RAM

9.  Experimentation and Performance

   This section presents some simple results obtained using the
   Deuterium HTTP/2 library [Deuterium] and is not intended to be
   complete, but rather a start for discussion.  From an IoT
   perspective, the reduced message sizes presented help to conserve
   both bandwidth and battery life, as well as potentially saving some
   memory/buffer space.

   The results presented in this section make the following assumptions
   and considerations:

   o  Overhead from TCP and TLS are ignored

   o  An attempt to minimize the headers used has been made while still
      maintaining RFC compliance

   o  No entries are made into the HTTP/2 dynamic table, thus removing
      some potential optimization

Montenegro, et al.       Expires January 9, 2017               [Page 13]

Internet-Draft                    H2oT                         July 2016

   o  Connection establishment and teardown have been ignored, though
      clearly these are important considerations for IoT application

   o  Only happy path transmissions are shown, thus no comparison of
      failure modes or retransmissions is given

9.1.  GET Example

   This first example compares and contrasts a GET method to a resource
   containing an XML representation of a simple switch using HTTP/1.1
   and HTTP/2.

9.1.1.  HTTP/1.1

   1.  Client sends (47 octets):

   4745 5420 2f6f 6e6f 6666 2048 5454 502f 312e 310d
   0a48 6f73 743a 2066 6f6f 0d0a 4163 6365 7074 3a20
   2a2f 2a0d 0a0d 0a

       In ASCII:

   GET /onoff HTTP/1.1\r\n
   Host: foo\r\n
   Accept: */*\r\n

   2.  Server sends (107 + 36 octets):

   4854 5450 2f31 2e31 2032 3030 204f 4b0d 0a44 6174
   653a 204d 6f6e 2c20 3039 204d 6172 2032 3031 3520
   3036 3a32 363a 3434 2047 4d54 0d0a 436f 6e74 656e
   742d 4c65 6e67 7468 3a20 3336 0d0a 436f 6e74 656e
   742d 5479 7065 3a20 6170 706c 6963 6174 696f 6e2f
   786d 6c0d 0a0d 0a
   3c4f 6e4f 6666 3e0a 093c 7374 6174 653e 6f66 663c
   2f73 7461 7465 3e0a 3c2f 4f6e 4f66 663e

       In ASCII:

Montenegro, et al.       Expires January 9, 2017               [Page 14]

Internet-Draft                    H2oT                         July 2016

   HTTP/1.1 200 OK\r\n
   Date: Mon, 09 Mar 2015 06:26:44 GMT\r\n
   Content-Length: 36\r\n
   Content-Type: application/xml\r\n

9.1.2.  HTTP/2

   1.  Client sends (34 octets):

   0000 1901 0500 0000 01
   8286 0585 60f5 1e59 7f01 8294 e70f 0489 f963 e7ef
   b401 5c00 07


   :method: GET
   :path: /onoff
   :scheme: http
   :authority: foo
   accept: */*

   2.  Server sends (54 octets):

   0000 2d01 0400 0000 01
   880f 1296 d07a be94 03ea 681d 8a08 016d 4039 704e
   5c69 a531 68df 0f10 8b1d 75d0 620d 263d 4c79 a68f
   0f0d 8265 cf


   :status: 200
   content-type: application/xml
   content-length: 36
   date: Mon, 09 Mar 2015 06:26:44 GMT

   3.  Server sends (45 octets):

   0000 2400 0100 0000 01
   3c4f 6e4f 6666 3e0a 093c 7374 6174 653e 6f66 663c
   2f73 7461 7465 3e0a 3c2f 4f6e 4f66 663e


Montenegro, et al.       Expires January 9, 2017               [Page 15]

Internet-Draft                    H2oT                         July 2016


9.1.3.  Comparison

   In total and ignoring the payload (36 octets), the HTTP/2 flow is 37%
   smaller than the HTTP/1.1 flow.

   The use of additional headers, particularly common headers that are
   present in the HTTP/2 static table, will result in greater savings.

   While not compared here, HTTP/2's ability to reuse connections for
   multiple streams reduces connection establishment overhead, such as
   TCP connection establishment and TLS session establishment.

10.  HTTP/2 over UDP - QUIC

   QUIC (Quick UDP Internet Connections) is a new multiplexed transport
   protocol designed to run in user space above UDP, optimized for
   HTTP/2 semantics.  In this document, "QUIC" refers to the upcoming
   IETF standard.  The protocol is still in its early days and the
   standardization work in IETF has just started.

   QUIC provides functionality already present in TCP and HTTP/2

   o  connection semantics, reliability, and congestion control
      equivalent to TCP.

   o  multiplexing and flow control equivalent to HTTP/2

   Where functionality is similar to that of existing protocols, it has
   been re-designed to be more efficient.  For example, the native
   multistream provides multiplexing without the head-of-line blocking
   inherent to HTTP/2 over TCP.

   QUIC will use DTLS 1.3.  Accordingly, connections will commonly
   benefit from 0-RTT as defined by TLS 1.3, meaning that on most QUIC
   connections, data can be sent immediately without waiting for a reply
   from the server.  Furthermore, packets are always authenticated and
   typically the payload is fully encrypted.

   QUIC has been designed to provide richer information to congestion
   control algorithms than TCP, moreover the actual congestion control
   is plugable in QUIC.

   Even if QUIC has been initially designed with HTTP/2 as the primary
   application protocol to support, it is meant to become a modern

Montenegro, et al.       Expires January 9, 2017               [Page 16]

Internet-Draft                    H2oT                         July 2016

   general-purpose transport protocol.  The IETF standardization effort
   will also focus on describing the mapping of HTTP/2 semantics using
   QUIC specifically with the goal of minimizing web latency using QUIC.
   This mapping will accommodate the extension mechanisms defined in the
   HTTP/2 specification.

   QUIC also dictates that packets should be sized to fit within the
   path's MTU to avoid IP fragmentation.  However path MTU discovery is
   work in progress, and the current QUIC implementation uses a
   1350-byte maximum QUIC packet size for IPv6, 1370 for IPv4.

   Judging from its current state, QUIC may bring some potential
   benefits like the possibility to design and use a specific congestion
   control algorithm suited to IoT scenarios and possibility to reduce
   header overhead as compared to that of TCP plus HTTP/2.  The latter
   is possible since these two layers are more integrated in QUIC.

11.  IANA Considerations

   This document has no considerations for IANA.

12.  Security Considerations

   Section 1 and Section 3 above point out security issues in the
   current IoT landscape, namely, the additional attack vectors from
   having several bespoke stacks instead of one mainstream stack and
   protocols.  This document seeks to improve security of the IoT by
   encouraging use of mainstream protocols which are better understood
   and more thoroughly debugged (both in their specifications as well as
   in their implementations).

   Section 7 point out another issue with the current IoT landscape: the
   proliferation of gateways and proxies.  Whereas they serve useful
   functions in IoT, allowing more constrained nodes to have much lower
   duty cycles or filtering them from much traffic, there are inherent
   security issues, not the least of which is that they break end-to-end
   security.  Enabling more mainstream protocols would not preclude
   using a proxy or gateway whenever the tradeoff dictated it, but would
   also allow for end-to-end security.

   Given the security challenges in IoT scenarios, HTTP/2 is assumed to
   use TLS services.  In Internet scenarios, [RFC7540] has clear
   guidance in this respect.  In Constrained network scenarios, the
   guidance for IoT is [I-D.ietf-dice-profile].  However, these are
   currently at odds.  For example, Section 4.2 of
   [I-D.ietf-dice-profile] mandates the ciphersuite
   TLS_PSK_WITH_AES_128_CCM_8 for preshared key-based authentication
   (quite common in IoT deployments).  On the other hand, Appendix A of

Montenegro, et al.       Expires January 9, 2017               [Page 17]

Internet-Draft                    H2oT                         July 2016

   [RFC7540] includes TLS_PSK_WITH_AES_128_CCM_8 in the HTTP/2 Black
   List of disallowed cipher suites, despite it being an AEAD
   ciphersuite.  This is still to be resolved.  The other IoT
   ciphersuite mandated by [I-D.ietf-dice-profile], namely,
   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (used for both certificate-based
   and Raw Public Key-based authentication) is not on the HTTP/2 Black

13.  Acknowledgements

   Thanks to the following individuals for helpful comments and
   discussion: Brian Raymor, Dave Thaler, Ed Briggs.

   This document was produced using the xml2rfc tool [RFC2629][RFC7749].

14.  References

14.1.  Normative References

              Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the
              Internet of Things", draft-ietf-dice-profile-17 (work in
              progress), October 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,

   [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
              DOI 10.17487/RFC7232, June 2014,

   [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
              "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
              RFC 7233, DOI 10.17487/RFC7233, June 2014,

Montenegro, et al.       Expires January 9, 2017               [Page 18]

Internet-Draft                    H2oT                         July 2016

   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,

   [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,

14.2.  Informative References

   [Clapper]  "US intelligence chief: we might use the internet of
              things to spy on you", February 2016,

              Giang, N., Ha, M., and D. Kim, "SCoAP: An integration of
              CoAP protocol with web-based application", Proc. IEEE
              GLOBECOM , 2013.

              Simpson, R., "Deuterium HTTP/2 Library", June 2016,

              Eclipse Foundation, "IoT Developer Survey", April 2016,

              "Dont Panic: Making Progress on Going Dark Debate",
              February 2016, <https://cyber.law.harvard.edu/pubrelease/

Montenegro, et al.       Expires January 9, 2017               [Page 19]

Internet-Draft                    H2oT                         July 2016

              Aggarwal, A., "Optimizing DNS-SD query using TXT records",
              draft-aggarwal-dnssd-optimize-query-00 (work in progress),
              July 2014.

              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE)", draft-ietf-ace-oauth-
              authz-02 (work in progress), June 2016.

              Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M.,
              and M. Ayyash, "Internet of Things: A Survey on Enabling
              Technologies, Protocols, and Applications", IEEE
              Communication Surveys and Tutorials , November 2015.

              Colina, M., Bartolucci, M., Vanelli-Coralli, A., and G.
              Corazza, "Internet of Things application layer protocol
              analysis over error and delay prone links", Proc. ASMS/
              SPSC Conference , 2014.

              ISO, "ISO/IEC 20922:2016 Information technology -- Message
              Queuing Telemetry Transport (MQTT) v3.1.1", June 2016,

              OASIS, "MQTT Version 3.1.1 becomes an OASIS Standard",
              October 2014, <https://www.oasis-

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,

Montenegro, et al.       Expires January 9, 2017               [Page 20]

Internet-Draft                    H2oT                         July 2016

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,

   [RFC7749]  Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
              RFC 7749, DOI 10.17487/RFC7749, February 2016,

              Lerche, C., Laum, N., Golatowski, F., Timmermann, D., and
              C. Niedermier, "Connecting the web with the web of things:
              lessons learned from implementing a CoAP-HTTP proxy",
              Proc. IEEE MASS , 2012.

Authors' Addresses

   Gabriel Montenegro

   Email: Gabriel.Montenegro@microsoft.com

   Sandra Cespedes
   NIC Chile Research Labs, Universidad de Chile

   Email: scespedes@ing.uchile.cl

   Salvatore Loreto

   Email: salvatore.loreto@ericsson.com

   Robby Simpson
   General Electric

   Email: rsimpson@gmail.com

Montenegro, et al.       Expires January 9, 2017               [Page 21]