<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-abilash-quic-network-00" ipr="trust200902">
  <front>
    <title abbrev="QUIC Network">Network Enhancements for QUIC</title>

    <author fullname="Abilash Menon" initials="A." surname="Menon">
      <organization>128 Technology</organization>

      <address>
        <email>amenon@128technology.com</email>
      </address>
    </author>

    <author fullname="Ritesh Mukherjee" initials="R." surname="Mukherjee">
      <organization>128 Technology</organization>

      <address>
        <email>rmukherjee@128technology.com</email>
      </address>
    </author>

    <date/>

    <workgroup>QUIC</workgroup>

    <abstract>
      <t>QUIC aims to improve performance by multiplexing streams and various
      other enhancements <xref target="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 <xref
      target="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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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.</t>

      <t>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.</t>
    </section>

    <section title="Conventions and Definitions">
      <t>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.</t>

      <t>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.</t>

      <t>Definition of terms that are used in this document:</t>

      <t><list style="symbols">
          <t>Client: The endpoint initiating a QUIC connection.</t>

          <t>Server: The endpoint accepting incoming QUIC connections.</t>

          <t>Stream: A logical, bi-directional channel of ordered bytes within
          a QUIC connection.</t>

          <t>Stream ID: The identifier for streams within a QUIC
          connection.</t>

          <t>Connection: A conversation between two QUIC endpoints with a
          single encryption context that multiplexes streams within it.</t>

          <t>Connection ID: The identifier for a QUIC connection.</t>

          <t>Initiation Edge: The first network element on the path from the
          Client to the Server that supports QUIC network optimizations.</t>

          <t>Termination Edge: The last network element on the path from the
          Client to the Server that supports QUIC network optimizations.</t>
        </list></t>
    </section>

    <section title="QUIC Network">
      <t>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.</t>

      <section title="Stream Header">
        <t>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.</t>

        <figure align="center">
          <artwork>+--------+--------+--------+--------+--------+------------+
|Type (8)| Stream ID (8, 16, 24, or 32 bits) |Priority (8)|
|        |    (Variable length SLEN bytes)   |            | 
+--------+--------+--------+--------+--------+------------+
</artwork>

          <postamble>Figure 1 QUIC Network Stream Header</postamble>
        </figure>

        <t><list style="symbols">
            <t>Type: Same as specified in the QUIC protocol.</t>

            <t>Stream ID: Same as specified in the QUIC protocol.</t>

            <t>Priority: Field indicating priority for each stream. It has
            values from 0-255. 0 indicates lowest priority and 255 indicates
            highest priority.</t>
          </list></t>

        <t>Stream 1 and Stream 3 will have the highest priority by default as
        they are special streams to carry initial handshake and headers
        respectively.</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Stream Demultiplexing and Multiplexing">
        <t>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).</t>

        <figure align="center">
          <artwork>                            Stream 5
                     ----------------------
                    /                      \
         +--------+/        Stream 7        \+--------+
Client---|Router 1|--------------------------|Router 2|---Server
         +--------+\                        /+--------+
                    \       Stream 9       /
                     ----------------------
       Initiation Edge                    Termination Edge
       </artwork>

          <postamble>Figure 2 QUIC Sample Network</postamble>
        </figure>

        <t>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.</t>
      </section>

      <section title="Multi-Path">
        <t>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.</t>
      </section>

      <section title="Moving Streams">
        <t>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.</t>
      </section>

      <section title="QUIC State Machine">
        <t>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:</t>
      </section>

      <section title="Stream based Packet Pacing">
        <t>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.</t>

        <t><list style="counter">
            <t>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.</t>

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

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

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

            <t>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.</t>

            <t>A connection termination would terminate all stream
            sessions.</t>
          </list></t>

        <t>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.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations for QUIC network enhancements are
      believed to be the same as for QUIC.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document has benefited from input from Patrick MeLampy.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.I-D.ietf-quic-transport.xml"?>
    </references>

    <references title="Informative References">
      <reference anchor="MEG2016">
        <front>
          <title>How quick is QUIC</title>

          <author initials="P.M." surname="Megyesi">
            <organization/>
          </author>

          <author initials="Z.K." surname="Kramer">
            <organization/>
          </author>

          <author initials="S.M." surname="Molnar">
            <organization/>
          </author>

          <date day="23-27" month="May" year="2016"/>
        </front>

        <seriesInfo name="Proc. IEEE ICC 2016," value="Kuala Lumpur, Malaysia"/>
      </reference>
    </references>
  </back>
</rfc>
