Internet DRAFT - draft-abilash-quic-network

draft-abilash-quic-network







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

Abstract

   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.

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 July 8, 2017.

Copyright Notice

   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



Menon & Mukherjee         Expires July 8, 2017                  [Page 1]

Internet-Draft                QUIC Network                  January 2017


   (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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  QUIC Network  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Stream Header . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Stream Demultiplexing and Multiplexing  . . . . . . . . .   4
     3.3.  Multi-Path  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Moving Streams  . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  QUIC State Machine  . . . . . . . . . . . . . . . . . . .   5
     3.6.  Stream based Packet Pacing  . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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




Menon & Mukherjee         Expires July 8, 2017                  [Page 2]

Internet-Draft                QUIC Network                  January 2017


   perform better than traditional transport protocols in all network
   conditions.

2.  Conventions and Definitions

   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:

   o  Client: The endpoint initiating a QUIC connection.

   o  Server: The endpoint accepting incoming QUIC connections.

   o  Stream: A logical, bi-directional channel of ordered bytes within
      a QUIC connection.

   o  Stream ID: The identifier for streams within a QUIC connection.

   o  Connection: A conversation between two QUIC endpoints with a
      single encryption context that multiplexes streams within it.

   o  Connection ID: The identifier for a QUIC connection.

   o  Initiation Edge: The first network element on the path from the
      Client to the Server that supports QUIC network optimizations.

   o  Termination Edge: The last network element on the path from the
      Client to the Server that supports QUIC network optimizations.

3.  QUIC Network

   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.





Menon & Mukherjee         Expires July 8, 2017                  [Page 3]

Internet-Draft                QUIC Network                  January 2017


3.1.  Stream Header

   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

   o  Type: Same as specified in the QUIC protocol.

   o  Stream ID: Same as specified in the QUIC protocol.

   o  Priority: Field indicating priority for each stream.  It has
      values from 0-255. 0 indicates lowest priority and 255 indicates
      highest priority.

   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.

3.2.  Stream Demultiplexing and Multiplexing

   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




Menon & Mukherjee         Expires July 8, 2017                  [Page 4]

Internet-Draft                QUIC Network                  January 2017


   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.

3.3.  Multi-Path

   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.

3.4.  Moving Streams

   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.

3.5.  QUIC State Machine

   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:







Menon & Mukherjee         Expires July 8, 2017                  [Page 5]

Internet-Draft                QUIC Network                  January 2017


3.6.  Stream based Packet Pacing

   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.

      When a QUIC packet with a new Connection ID is received, it will
      validate that the Stream ID of this packet is 1.  Stream 1 will
      have the highest priority.

      Any subsequent packet with a different Stream ID will create a new
      sub-session for this Connection ID and stream.

      If a FIN is seen in both directions for a stream, then the session
      for that stream will be removed from the router.

      If a RST_STREAM is received, then the session for that stream will
      be terminated in the router.

      Once a stream session has been terminated, any new packets with
      that Stream ID will not be forwarded and will be responded to with
      a RST_STREAM packet.

      A connection termination would terminate all stream sessions.

   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.

4.  IANA Considerations

   This document makes no request of IANA.

5.  Security Considerations

   The security considerations for QUIC network enhancements are
   believed to be the same as for QUIC.






Menon & Mukherjee         Expires July 8, 2017                  [Page 6]

Internet-Draft                QUIC Network                  January 2017


6.  Acknowledgements

   This document has benefited from input from Patrick MeLampy.

7.  References

7.1.  Normative References

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-00 (work
              in progress), November 2016.

7.2.  Informative References

   [MEG2016]  Megyesi, P., Kramer, Z., and S. Molnar, "How quick is
              QUIC", Proc. IEEE ICC 2016, Kuala Lumpur, Malaysia, May
              2016.

Authors' Addresses

   Abilash Menon
   128 Technology

   Email: amenon@128technology.com


   Ritesh Mukherjee
   128 Technology

   Email: rmukherjee@128technology.com




















Menon & Mukherjee         Expires July 8, 2017                  [Page 7]