| QUIC | A. Menon |
| Internet-Draft | R. Mukherjee |
| Intended status: Standards Track | 128 Technology |
| Expires: July 8, 2017 | January 4, 2017 |
Network Enhancements for QUIC
draft-abilash-quic-network-00
QUIC aims to improve performance by multiplexing streams and various other enhancements [I-D.ietf-quic-transport]. QUIC performs better than existing transport protocols in most cases. However, its performance suffers compared to HTTP under very high bandwidth when large amounts of data needs to be downloaded [MEG2016]. This is because QUIC is an end to end protocol and provides no means for the intermediate network elements to contribute to QUIC improvements. This draft proposes a change to the QUIC protocol header that will allow session aware routers and other middleboxes to prioritize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per stream basis. This opens the door to many possible future in-network enhancements.
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 July 8, 2017.
Copyright (c) 2017 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.
QUIC employs stream multiplexing by interleaving frames from multiple streams into one conversation between QUIC endpoints. These streams are identified by a Stream ID and multiplexed on top of the same UDP flow. These streams do not have any priority assigned to them and all of them are treated with the same priority. A high priority stream is affected by network conditions similar to low priority streams. [MEG2016] shows studies where HTTP performs better than QUIC because it opens multiple connections for each stream. When large amounts of data are to be downloaded and when there is high bandwidth available, QUIC underperforms compared to HTTP.
This draft proposes to make the Stream ID visible in the public header and add a priority byte. Session aware routers and other middleboxes can demultiplex streams at the initiator edge and multiplex them back at the termination edge. With these enhancements QUIC now simulates opening multiple connections similar to HTTP with priorities in high bandwidth cases. Coupled with inherent QUIC protocol enhancements and network participation, QUIC will be able to perform better than traditional transport protocols in all network conditions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119.
Definition of terms that are used in this document:
Modern Enterprise WAN or SD-WAN deployments are moving towards session/flow aware routing which provides insight into applications for improved performance. These typical WAN deployments have edge routers at the Client and Server side which would originate and terminate sessions. These sessions could be based on the unique five tuple of the packet or any other application attribute that makes it unique. The Connection ID of the QUIC protocol is a natural identifier to classify QUIC sessions. Each QUIC Connection will have a unique session within these session aware routers or middleboxes.
The Stream ID of the stream multiplexed into a QUIC connection with a Connection ID must be visible in the public header. A priority byte is added to indicate relative priority of the stream.
+--------+--------+--------+--------+--------+------------+ |Type (8)| Stream ID (8, 16, 24, or 32 bits) |Priority (8)| | | (Variable length SLEN bytes) | | +--------+--------+--------+--------+--------+------------+
Figure 1 QUIC Network Stream Header
Stream 1 and Stream 3 will have the highest priority by default as they are special streams to carry initial handshake and headers respectively.
QUIC packets are always authenticated and the payload is typically fully encrypted. The parts of the packet header which are not encrypted are still authenticated by the receiver, so as to thwart any packet injection or manipulation by third parties. There is no change in this and is as defined in the QUIC protocol.
A public flag needs to be set by the Client as an indication to the network elements to demultiplex the packets on a per stream basis. This can be done during the initial crypto handshake (stream 1). The client can set this flag requesting network elements to apply QUIC optimizations. The network elements that honor these requests can reset this flag on the return from the Server. This allows the client to learn that it can rely on the network for QUIC related network optimizations. Public flag 0x80 is currently unused and can could be used for this purpose.
Session aware routers and middleboxes can demultiplex streams at the Initiation Edge and multiplex them back at the Termination Edge. Consider a QUIC connection that has 3 streams all initiated by the Client. In Figure 2, QUIC packets with Stream IDs 5, 7, and 9 are sent across as 3 different flows between router 1 (Initiation Edge) and router 2 (Termination Edge).
Stream 5
----------------------
/ \
+--------+/ Stream 7 \+--------+
Client---|Router 1|--------------------------|Router 2|---Server
+--------+\ /+--------+
\ Stream 9 /
----------------------
Initiation Edge Termination Edge
Figure 2 QUIC Sample Network
Multiplexing the connection across multiple flows during high bandwidth and high loss network conditions when large amounts of data are being downloaded spreads the packet losses across these different flows. By setting the priority of these streams it is possible to ensure that high value flows do not incur any losses.
Exposing the Stream ID and its priority can help prioritize traffic across different paths. In typical SD-WAN deployments there are multiple paths – usually a high cost MPLS path and a lower cost Internet path. By prioritizing streams, high value streams could be sent over the MPLS path while lower value streams can be sent over the Internet path.
In other deployments, the Internet path can be used to send all traffic and when there are packet losses discovered beyond acceptable limits then the Initiation Edge can switch high value streams to the MPLS path. SD-WAN routers provide many such enhancements that applications supporting QUIC can avail by exposing the Stream ID.
A QUIC state machine can be employed on a per stream basis on these session aware routers. The state machine helps with the life cycle of the session (creation/termination). The proposed state machine will do the following:
QUIC employs a packet pacing mechanism based on the inter-packet arrival rate. However, session aware routers will have a flow per stream. Hence the packet rate can be adjusted on a per stream basis and not for the whole connection. For example, if there are 3 streams 5, 7, and 9. Stream 5 and 7 may have good inter-arrival rate while stream 9 may experience some delay due to network conditions. In this scenario, the packets can be paced differently just for stream 9 which was affected by the network and not the other streams. Streams 5 and 7 can continue to provide high throughput results without affecting their latency. This can help with congestion control techniques.
The state machine need not be limited to the above functionalities. This can also be useful to employ per stream flow and congestion control techniques.
This document makes no request of IANA.
The security considerations for QUIC network enhancements are believed to be the same as for QUIC.
This document has benefited from input from Patrick MeLampy.
| [I-D.ietf-quic-transport] | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Internet-Draft draft-ietf-quic-transport-00, November 2016. |
| [MEG2016] | Megyesi, P., Kramer, Z. and S. Molnar, "How quick is QUIC", Proc. IEEE ICC 2016, Kuala Lumpur, Malaysia, May 2016. |