QUIC Plugins

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 https://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 10 September 2020.¶

Copyright Notice

Copyright (c) 2020 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 (https://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

Internet hosts rely on protocols to efficiently exchange information. Most protocols are designed assuming a layered model. In such a layered protocol model, a protocol implementation is often represented as a black-box that uses the service provided by the underlying layer to offer an enhanced Application Programming Interface (API) to the upper layer. This is illustrated in Figure 1.¶

Layer N+1
---------- +----------- API -----------+
Management |                           |
Protocol   |                           |
<--------->|  Protocol implementation  |
           |                           |
           +---------------------------+
                 ||         /\
                 \/         ||
-----------------------------------
Layer N-1

Different protocols expose different APIs. In the transport layer, the socket API is the most popular one. It was originally defined with the TCP and UDP protocols in mind, but has been extended to support SCTP [RFC6458] and Multipath TCP [RFC6897]. The TAPS working group is currently defining new APIs for the transport services [I-D.ietf-taps-interface].¶

An important benefit of having standardized APIs is that if two implementations expose the same API, it is possible to replace one by the other without changing anything in the upper layers.¶

Besides exposing an API to the layer above, many protocol implementations also expose an API to management protocols such as SNMP, IPFIX or NETCONF. For example, a TCP implementation exposes the variables and tables defined in the TCP part of the MIB-2 [RFC1213][RFC4022]. There is ongoing work in developing a YANG model for TCP implementations [I-D.scharf-tcpm-yang-tcp]. This is illustrated in the left part of Figure 1.¶

These management APIs expose abstract configuration parameters and statistics about the key operations performed by a protocol implementation to offer more control to the upper layer. They have been useful in configuring and operating a wide range of protocol implementations. As different implementations expose the same abstraction, it becomes possible for operators to configure and manage different implementations by using the same tool in a unified manner.¶

A protocol implementation exchanges messages with other implementations by leveraging the service provided by the underlying layer. For example, a TCP implementation interacts through the socket API and exchanges TCP segments with remote hosts through the underlying IP protocol. Protocol designers usually define transport and application protocols in two parts:¶

• a series of messages that are encoded using a specific format.¶
• a Finite State Machine that defines how hosts react to commands from the layer above or to the reception of a specific message.¶

This model has been used to represent a wide range of Internet protocols. Typically, the Finite State Machine and the syntax of the messages are described in a single or a series of documents that are heavily discussed within IETF working groups before reaching a consensus and getting a final specification. The ongoing work on the finalization of the first version of the QUIC specification is a recent example of such efforts [I-D.ietf-quic-transport].¶

Once the first stable version of the specification of a protocol has been approved, IETF working groups typically observe the deployment of the protocol and improve it based on the received feedback. If the protocol is successful, it often triggers suggestions for extensions or improvements. These extensions are important for these successful protocols, but they often take a lot of time to be deployed. Experience with TCP shows that extensions, such as selective acknowledgments [RFC2018], support for large windows and timestamps [RFC7323] or more recently Multipath TCP [RFC6824] took more than a decade to be widely deployed. There are several considerations that can explain the difficulty of deploying TCP extensions, ranging from the fact that TCP is often part of operating system kernels, which evolve at a slower pace than applications, to middlebox interference.¶

Looking at other IETF protocols, we rarely observe successful protocols that have not been extended over the years. Thus, the need for extensibility could be seen as an invariant for a successful Internet protocol. In addition to the extensions that were accepted by the IETF and eventually deployed, there are many other extensions that correspond to specific applications or more restricted use cases. These extensions would be very valuable in specific environments, but their proponents never managed to convince the relevant IETF working group and implementers of their benefits.¶

Besides the protocol extensions, we also observe that there are some protocol behaviors that can be difficult to precisely express using a set of parameters that are exchanged inside a message. Here are two recent examples that illustrate this difficulty.¶

A first example is the transmission of acknowledgments in reliable transport protocols. There is a trade-off between the feedback provided by the acknowledgments and the resources (bandwidth and CPU) required to generate and process them. Various heuristics have been proposed in TCP to generate these ACKs [RFC1122],[RFC5681],[RFC3449],[RFC5690]. These heuristics are deployed independently on receivers, but for some of them the senders need to adapt by at least taking into account the fact that some acknowledgments were delayed while measuring the round-trip-time. A similar discussion has started for QUIC. Given the flexibility of QUIC, researchers have proposed to define an acknowledgment strategy as a set of parameters that are exchanged in a new QUIC frame over each connection [I-D.fairhurst-quic-ack-scaling],[I-D.iyengar-quic-delayed-ack]. This brings more flexibility than in TCP where the limited size of the header made it impossible to exchange such information.¶

A second example in the application layer is the support for stream priorities in HTTP/2 [RFC7540]. Since HTTP/2 provides parallel streams, some application developers have expressed their need for prioritizing some streams over others. The HTTP/2 protocol defines such priorities, but they are not widely used and some have proposed to deprecate them [I-D.peon-httpbis-h2-priority-one-less]. In spite of this, a proposal for stream prioritization for HTTP/3 already exists [I-D.kazuho-httpbis-priority]. [LNBIP2020] evaluates stream scheduling for HTTP/3 and claims that performances are heavily impacted by the adopted stream scheduling.¶

These examples illustrate the difficulty of precisely expressing complex behaviors in a few parameters that are exchanged inside packets.¶

In this document, we propose a different approach to specify and implement protocols to better address the extensibility requirement. We focus on the QUIC protocol in this document, but similar ideas could be applied to other IETF protocols or networking systems. We leverage the recent results in extending operating system kernels [eBPF] or web-browsers [WebAssembly] with virtual machines that execute bytecodes to propose a new approach to define complex behaviors inside protocols. We first describe the general architecture of the proposed approach in Section 2. We then provide a few examples showing how such an approach could be applied to the next version of the QUIC protocol in Section 3.¶

2. Dynamically extensible protocol implementations

Experience with successful Internet protocols shows that once a protocol gets (widely) deployed, it attracts new use cases and proposals to extend and improve it. Most of the key Internet protocols, including IP, TCP, HTTP, DNS, BGP, OSPF, IS-IS, ... have been improved over the years. Today, the developer of an implementation of any of these protocols need to consult dozens of RFCs to find their complete specification.¶

Despite the importance of extensions to those key Internet protocols, we still do not design them under the assumption that they will evolve over decades and that their implementations should be made agile. In this document, we propose a new organization for protocol implementations. Instead of trying to pack as many features as possible inside a protocol implementation that is considered as a blackbox, we consider a protocol implementation as an open system which can be extended to support new features in a safe and agile manner. Our vision is that such an implementation exposes an internal Plugin API which can be leveraged by code extensions that we call Plugins in this document. This is illustrated in Figure 2.¶

Layer N+1
---------- +----------- API -----------+
Management |  ( )       ( )       (x)<------ Plugin_A
Protocol   |                           |
<--------->|  Protocol implementation  |
           |       ( )       (x)<--------- Plugin_B
           +---------------------------+
                 ||         /\
                 \/         ||          Legend:
---------------------------------------    ( ) Part of the Plugin API
Layer N-1                                  (x) Plugin injected

These Plugins extend the protocol by modifying its messages or its Finite State Machine. Consider Figure 3 as an example which illustrates a simple receiver with three states, i.e. Receiving, Data rcvd and Ack needed. This receiver waits until either two data packets have been received or 10 milliseconds have passed after receiving a data packet before sending an acknowledgment. Its implementation consists of three actions, receive(), send_ack() and wait().¶

An application using this receiver could benefit from tuning this acknowledgment policy. For instance, another state could be chained between Data rcvd and Ack needed, so that acknowledgments can be batched for more than two data packets. Similarly, a more advanced heuristic could be added to generate acknowledgments, e.g. taking into account the size of data packets to detect transmission tails.¶

+-----------+  receive()  +-----------+
| Receiving |>----------->| Data rcvd |
+-----------+             +-v-------v-+
          ^                 |       |
          |        wait(10) |       | receive()
          |                 |       |
          |                 |       |
          |  send_ack()  +--v-------v-+
          \-------------<| Ack needed |
                         +------------+

Using this Plugin API, a protocol can be extended to add new messages and to modify its Finite State Machine, i.e. modify its states and transitions. This document defines such protocol as a pluginized protocol. Figure 4 illustrates how this simple receiver could be extended. In this example a new state is added so that a single acknowledgment can be sent for three received data packets.¶

+-----------+  receive()  +-----------+  receive()  *+++++++++++++*
| Receiving |>----------->| Data rcvd |>+++++++++++>| Data rcvd 2 |
+-----------+             +-v---------+             *+v+++++++++v+*
          ^                 |                         !         !
          |        wait(10) |                wait(5)  !         !
          |                 |       /+++++++++++++++++/         !
          |                 |       !                           !
          |  send_ack()  +--v-------v-+        receive()        !
          \-------------<| Ack needed |<++++++++++++++++++++++++/
                         +------------+
Legend:
  >+++> Transition added by a Plugin
  *+++*
  | S | State added by a Plugin
  *+++*

Due to space constraints, the case of adding a new action is not depicted in Figure 4. In this example, a new action data_not_full() could be added by a Plugin. This action could be taken whenever the last received data packet is not full, indicating the end of a series of packets. Transitions from the states Data rcvd and Data rcvd 2 to the state Ack needed with this action could be added by this Plugin.¶

3. Pluginizing QUIC

Conceptually, we break down a QUIC implementation execution flow into generic subroutines. These are specified functions called protocol operations. These protocol operations implement a given part of the QUIC protocol, for example the acknowledgment generation or the computation of the round-trip-time. Some are generic and depend on a parameter, for instance parsing a QUIC frame is a generic operation that depends on the type of QUIC frame. This version of the document does not elaborate exhaustively on the protocol operations composing a Pluginized QUIC implementation. The next versions of this document will work on defining a set of protocol operations.¶

A QUIC Plugin consists of platform-independent bytecode which modifies or extends the behavior of a QUIC implementation. Adding the functionality of a QUIC Plugin consists in adding or replacing a set of protocol operations implemented by this bytecode. This action of adding a QUIC Plugin to a QUIC connection is referred to as injecting a QUIC Plugin. Injecting a plugin is limited to a given QUIC connection.¶

Its bytecode is run inside a sandboxed execution environment. It has restricted access to the state of a QUIC connection through the Plugin API.¶

The scope of a QUIC Plugin is restricted by both the limitations of this execution environment, e.g. in terms of instruction set and quantity, and by the surface exposed by the Plugin API, e.g. the quantity of state that can be read from or written to by a plugin. The Plugin API also defines a set of protocol operations to which QUIC Plugins can be injected. For instance, a QUIC implementation might restrict QUIC Plugins injection to its acknowledgment generation policy, e.g. the protocol operation deciding whether sending an ACK frame is needed.¶

A QUIC Plugin can be injected by several means. The application can inject plugins to tune its underlying QUIC connection. QUIC peers can exchange and inject plugins over a QUIC connection, as described in Section 4. Users can set a default configuration injecting plugins on their devices.¶

Considering again Figure 3 applied to QUIC Plugins, the actions are the protocol operations. The states of the FSM are defined by the QUIC connection state, which can be modified and extended during the execution of a protocol operation through the Plugin API. The transitions are calls to protocol operations.¶

4. Exchanging QUIC Plugins

Injecting QUIC Plugins locally allows the application to tune the underlying QUIC implementation to its needs. But some use-cases requires adapting the peer behavior. In those cases, being able to exchange plugins helps to fill this gap.¶

QUIC offers both data multiplexing and encryption. Using those mechanisms, the QUIC Plugins used for a given connection could be safely transferred over this connection in a new dedicated stream, akin to the crypto stream. This does not impact the application data transfer, as illustrated in Figure 5. In this example, an HTTP/3 request is interleaved with the transfer from the server to the client of a QUIC Plugin controlling the acknowledgment policy.¶

 Client                             Server
  |     (QUIC connection handshake)     |
  |                                     |
  |       STREAM[0, "HTTP/3 GET"]       |
  |------------------------------------>|
  |                                     |
  |       STREAM[0, "200 OK..."]        |
  |<------------------------------------|
  |                                     |
  |    PLUGIN["ack_delay", bytecode]    |
  |<------------------------------------|
  |                                     |
  |       STREAM[0, "...", FIN]         |
  |<------------------------------------|

A local policy could restrict the type of plugins that can be exchanged and injected, e.g. in terms of connection state accessed and in terms of protocol operations affected. This version of document does not describe further how the negotiation of QUIC Plugins takes place.¶

QUIC Plugins could also be transferred out of band. The application using QUIC can then inject these plugins locally.¶

5. Examples of use-cases

There exist several cases in which being able to modify the behavior of a QUIC peer, either locally or remotely, is beneficial. This first version of the document focus on enabling the extension of simple QUIC mechanisms. Three of them are documented in this section. Contributions to this document regarding new uses-cases are welcomed.¶

6. QUIC Plugins Authenticity

When exchanging and injecting QUIC Plugins, guaranteeing there authenticity and safety is important. This section describes two possible approaches for this purpose, the first guarantees the authenticity of the QUIC Plugins, the second guarantee both their authenticity and an open set of security properties with regard to QUIC Plugins.¶

7. Security Considerations

The next versions of this document will elaborate on security considerations following the guidelines of [RFC3552]. Moreover, this document will consider privacy as part of those considerations.¶

8. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

The authors of Pluginizing QUIC are thanked again for their work that initiated this proposal. This work was partially supported by the MQUIC project.¶

Authors' Addresses