[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                             N. Kuhn, Ed.
Internet-Draft                                                      CNES
Intended status: Informational                           E. Stephan, Ed.
Expires: May 6, 2020                                              Orange
                                                       G. Fairhurst, Ed.
                                                  University of Aberdeen
                                                        November 3, 2019


               Transport parameters for 0-RTT connections
                      draft-kuhn-quic-0rtt-bdp-04

Abstract

   The time-to-service duration depends on both peers exchange
   optimization.  The peer initiating the connection may not be the one
   which send data first.  Moreover, clients may be resource-limited,
   behind a low bandwidth or connected to a long-RTT network and may
   need to adapt dynamically to improve data reception.  Currently, each
   side has its proprietary solution to measure and to store path
   characteristics.  Having a standard way to share these parameters
   should improve the adaptation to a non standard path characteristics.

   QUIC v1 specification already reflects this approach.  Having a
   symmetrical control of the optimization should reduce protocol
   ossification.  This memo proposes the sharing of the characteristics
   of the path amongst the peer to reduce HTTP3 time-to-service for non
   default transport situation.

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 May 6, 2020.






Kuhn, et al.               Expires May 6, 2020                  [Page 1]


Internet-Draft             Transport for 0-RTT             November 2019


Copyright Notice

   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Reducing ossification with the proposed solution  . . . .   4
   2.  Differences between 1-RTT and 0-RTT QUIC connections
       establishment . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  An end-to-end Method  . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Description of the BDP metadata extension . . . . . . . .   5
     3.2.  Usage of the extension in the NewSessionTicket  . . . . .   6
   4.  Best current practice . . . . . . . . . . . . . . . . . . . .   6
   5.  What happens when BDP is used incorrectly?  . . . . . . . . .   8
   6.  Relevance of the solution for QUIC and other protocols  . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Some network paths experience an increased time-to-service because
   the default parameters controlling the initialization of the
   transport and congestion control are not well-suited to the path
   characteristics.  QUIC's default congestion control is based on TCP
   NewReno [I-D.ietf-quic-recovery] and the recommended initial window
   is defined by [RFC6928].  A path with a large bandwidth delay product
   can therefore significantly increase the time-to-service (e.g. a path
   using satellite communication [IJSCN19] could observe a much longer
   page load time for complex pages).  The 0-RTT mechanism is designed
   to accelerate the throughput when reconnecting to a peer where it has
   (recently) learned information about the path characteristics.



Kuhn, et al.               Expires May 6, 2020                  [Page 2]


Internet-Draft             Transport for 0-RTT             November 2019


   However, there are cases where egress acceleration like 0-RTT
   early_data alone does not improve the time-to-service and cases where
   the data transmission is symmetrical or where clients are capacity-
   limited: additional information can be beneficial.

   As QUIC transport security is based on TLS1.3 [I-D.ietf-quic-tls],
   this memo describes a solution where a BDP_metadata extension is
   added to the NewSessionTicket of TLS1.3 [TO DO ADD REF].  The
   BDP_metadata informs the client about path parameters so that both
   the client and the server can contribute to the reduction of the
   time-to-service.  This data is protected from in the middle-attack
   such as the 'early_data' extension.

   1.  the server learns characteristics of the path during a previous
       connection;

   2.  the server sends this information to the client at any time
       during the current connection, after the BDP_metadata parameters
       are validated;

   3.  the client is permitted to discard the information (when the
       validation period is too short, the information is found to be
       inconsistent with its own path characteristics measurement, for a
       device with limited buffer, etc.);

   4.  the server and the client can exploit the information to improve
       the time-to-service during subsequent 0-RTT connections.

   The current focus of this use is QUIC.  However, the method can be
   used with TLS1.3 over any transport (e.g., using this with TCP Fast
   Open [RFC7413] or DTLS [RFC6347].

   This proposal follows both the approach of the extension field
   'early_data' of the NewSessionTicket of TLS1.3 and its mapping in
   QUIC.  While 'early_data' improves the egress traffic of a client,
   the 'BDP_metadata' provides information that can be used to improve
   ingress traffic towards the client.  This can result in significant
   improvement to the quality-of-experience.  For example, it enables
   sending measured characteristics of the path, such as the RTT, PMTU
   and BDP.  This information can be used to adapt the initial data
   transmission of a 0-RTT connection.  In the case of a deployment
   scenario with a large BDP, this can halve the page load time of a web
   page download [TODO ADD REF].

   The proposal proposes to consider the same method for integrating
   TLS1.3 extension in QUIC as it is done for early_data.  For the
   mapping of NewSessionTicket in QUIC, QUIC transports the 'early_data'




Kuhn, et al.               Expires May 6, 2020                  [Page 3]


Internet-Draft             Transport for 0-RTT             November 2019


   value outside the NewSessionTicket in the "initial_max_data"
   transport parameters (see section 4.5 of [I-D.ietf-quic-tls]).

1.1.  Reducing ossification with the proposed solution

   While each client and server could implement a dedicated solution to
   exchange and store path parameters, providing a standard method to
   exchange this information helps provide symmetrical control of the
   optimisation.  This reduces protocol ossification.  A client using
   the method is informed about path parameters: allowing both the
   client and the server to reduce the time-to-service for subsequent
   connections.  This improves symmetrical transmission of data and
   reduces ossification of the protocol.  Some advantages of the
   proposed solution are the following.

   1.  It provides symmetrical control of the optimisation: as
       extensions to HTTP3 envision server initiated request
       [I-D.ietf-quic-http] the path adaptation ought to be symmetrical
       and ought not to depend on policy of the peer in establishment.
       The QUIC transport can be used for services beyond HTTP3,
       including symmetrical services: where QUIC is considered as a
       relevant candidate for setting up proxies or tunnels
       [I-D.kuehlewind-quic-substrate] or for transmiting unreliable
       datagram services [I-D.pauly-quic-datagram].  A client device
       sought to be able to adapt to the path chosen by the server.  A
       subscription where the server sends data first, it is important
       to dissociate the signalling (aka the initiator of the
       connection) from the peer that first sends application data.

   2.  Using the path information reduces the need for operators to
       deploy TCP-proxy and middleboxes, such as Performance-Enhancing
       Proxy (PEP) [RFC2488][RFC3135] to compensate for the
       characteristics of the paths: if both the client and server have
       learned appropriate transport parameters, they can themselves
       optimize the transport service by adapting the end-to-end
       transport protocol to the current path.  As example, specific
       client-based adaptations can be developed, such as adapting the
       ACK-ratio or increasing the receive buffer size.  This reduces
       the need to deploy middelboxes, and will result in less
       ossifiication along Internet paths.

   3.  Improve inter-operability: while each client and server can have
       their dedicated solution to store path parameters, having a
       standard way of exchanging this information helps in reducing the
       time-to-service when clients and servers are not provided by the
       same company.  Both sides can independently propose optimizations
       to improve the ingress traffic.




Kuhn, et al.               Expires May 6, 2020                  [Page 4]


Internet-Draft             Transport for 0-RTT             November 2019


2.  Differences between 1-RTT and 0-RTT QUIC connections establishment

   This section recalls how 1-RTT and 0-RTT operate in QUIC
   [I-D.ietf-quic-transport].

   QUIC leverages the two handshakes of TLS1.3 [I-D.ietf-quic-tls]: The
   1-RTT handshake initiates a first set of credentials.  When this
   handshake successfully completes, the server pushes the learned
   information about the session to the client in an opaque session
   ticket (see section 4.6.1 of [RFC8446]).  The information within the
   opaque ticket is encrypted by the server.  When received, the
   encrypted information is stored by the client (but is not readable by
   the client).  A session ticket can be sent at any time during the
   connection and a server can send several session tickets in one
   connection.  A client wishing to establish a fast re-open of the
   session pushes back the (stored) opaque ticket in its 0-RTT handshake
   and sends early application data.

   In practice, the server sends the 'ticket' in a NewSessionTicket
   record [I-D.ietf-quic-tls].  The structure of the NewSessionTicket
   includes the opaque 'ticket' and an 'extensions' field.  The
   NewSessionTicket carries an additional field named 'early_data' that
   indicates to the client the maximum size of application data to
   insert in the 0-RTT message.

3.  An end-to-end Method

   QUIC encryption of transport headers prevents the adding of
   Performance-enhancing proxy (PEP).  The BDP metadata extension may be
   a substitute to PEP proxy [RFC2488], [RFC3135] when time-to-service
   improvement requires acceleration of the refilling of client
   application buffers.

   The BDP_metadata extension allows a cient to recall the BDP metadata
   previously measured by the server during the 1-RTT handshake when it
   initializes a 0-RTT connection.  The approach enables changes to a
   congestion control method (e.g., tuning of the initial window for
   high BDP networks, as described in
   [I-D.irtf-iccrg-sallantin-initial-spreading].  This has been shown to
   improve performance both for paths with a high BDP and a more common
   BDP [CONEXT15][ICC16].

3.1.  Description of the BDP metadata extension

   This section defines an extension named "BDP_metadata" for the
   NewSessionTicket.  This structure contains the following parameters:
   BDP, MTU, RTT, loss-rate.




Kuhn, et al.               Expires May 6, 2020                  [Page 5]


Internet-Draft             Transport for 0-RTT             November 2019


3.2.  Usage of the extension in the NewSessionTicket

   At the end of a 1-RTT connection, a server can send information in a
   NewSessionTicket that describes the path to the client.  The message
   includes an additional 'extensions' field named 'BDP_metadata'.  The
   client stores this session ticket together with and the
   'BDP_metadata' field.

   When the client reconnects to the same server in 0-RTT mode, it
   pushes back this session ticket in the ClientHello and prepares
   itself to receive data in the context given by the 'BDP_metadata'
   field.  The client does not send the 'BDP_metadata' field back to the
   server.  The server receives the session ticket and extracts the BDP
   context.  As example, it can use this message to provide information
   that may allow the congestion controller to provide a throughput
   closer to the capacity of the path.

   The path characteristics can and do change over time.  The path
   information can therefore become invalid for use in a subsequent
   connection.  The server MUST set the age of the ticket (see section
   4.2.11.1 of [RFC8446]) to a short duration.  To help ensure that the
   ticket is still valid, the server SHOULD also verify the IP address
   of the client.  A server MAY update the ticket when the path
   characteristics of connection are known to have changed.

4.  Best current practice

   This section provides examples of data that could be added in the
   opaque session ticket field by the server.  The details added by the
   server in the session ticket do not need to be standardized for
   interoperability between QUIC clients and servers because this
   information is opaque to the client.  The presence of the
   "BDP_metadata" extension field in the NewSessionTicket informs the
   client that the server can actively take action to improve its
   throughput when the session will restart.

   The following list describes information elements set by the server
   in the session ticket to accompany the signaling of field.  These
   examples are illustrated in Figure 1 and their purpose is detailed in
   this section.

   o  A client aware of a high BDP path: Section 7.3.1 of
      [I-D.ietf-quic-transport] indicates that the "A client that
      attempts to send 0-RTT data MUST remember the transport parameters
      used by the server".  In addition to the default transport
      parameters used by the server, a server that knows that the path
      has a large BDP can let the client adapt its parameters.




Kuhn, et al.               Expires May 6, 2020                  [Page 6]


Internet-Draft             Transport for 0-RTT             November 2019


   o  PMTU: Knowledge of the PMTU of a previous path improves the time
      to service because it reduces the duration of the path validation
      process described in section 8.2 of [I-D.ietf-quic-transport].

   o  Connection RTT: The knowledge of the characteristics of a previous
      connection RTT can improve the throughput because a server can
      safely improve the slow start: e.g. using the pacing models of
      [I-D.irtf-iccrg-sallantin-initial-spreading] can utilise a larger
      IW for high RTT paths and a default IW for paths with smaller RTT.
      The results presented in [ICC16] show that for both files of 15 KB
      and 750 KB, the proposed solution reduces the time to download by
      approximatively 2 seconds whether the RTT is 50ms or 500ms.

   o  Ticket_lifetime: The server sets a shorter validity duration to
      avoid receiving obsolete path characteristics; (e.g., this could
      reduce the validity to one day).



































Kuhn, et al.               Expires May 6, 2020                  [Page 7]


Internet-Draft             Transport for 0-RTT             November 2019


              CLIENT                         SERVER
              +-----------------------------------+
              |          1 RTT connection         |
              +-----------------------------------+
                |                              |
                +<---1-RTT TLS1.3 HANDSHAKE--->+
                |                              | +------------+
                +<-----data transmission------>+ |path charact|
                |                              | |record      |
                |                              | +------------+
                |<-------------NewSessionTicket+
   +----------+ |           +ticket_lifetime   |
   |client    | |           +'opaque' field    |
   |aware of  | |           +'extension' field |
   |path      | |            + early_data      |
   |charat.   | |            + BDP_metadata    |
   +----------+ |              + BDP           |
                |              + RTT           |
                |              + loss-rate     |
                |              + MTU           |
              +-----------------------------------+
              |          0 RTT connection         |
              +-----------------------------------+
                |                              |
                +ClientHello------------------>|
                |+'opaque' field               |
                |                              | +-------------------+
                |                              | |server aware of    |
                |                              | |path charact.      |
                |                              | +-------------------+
                |                              |
                +<----+data transmission+----->+
                |                              |
                +                              +

                Figure 1: Example of opaque ticket content

5.  What happens when BDP is used incorrectly?

   This section discusses the impact of a server activating the
   'BDP_metadata' field when the network underneath actually has a small
   BDP.  This could happen when the server BDP estimate was incorrect,
   when a client has multiple paths to choose from and uses the ticket
   on a different path to which it was requested, or when the path
   characteristics have changed significantly.

   Incorrectly exploiting the BDP_metadata could result in pre-assigning
   additional resources (e.g. transport buffer space) that later fails



Kuhn, et al.               Expires May 6, 2020                  [Page 8]


Internet-Draft             Transport for 0-RTT             November 2019


   to be used.  Many endpoints implementations do not statically pre-
   assign buffer space, so increasing the limit does not have an impact
   when the resource is unused.  Some cases could be resource-limited.

   The server could adapt the initial window because it expects a high
   BDP path, when the actual BDP is significantly smaller.  This issue
   can be mitigated when packets are paced from the server over the
   associated RTT, since the server would receive an acknowledgment
   after the actual RTT period, and before it has used the complete
   initial window.

6.  Relevance of the solution for QUIC and other protocols

   The QUIC framework would allow solutions to have been proposed.  As
   an example, the NEW_TOKEN frame could be used to send the path
   characteristics information to the client.  However, this would
   require specifying its content, consistently with QUIC transport
   parameters, so that any client can exploit the information
   transmitted by any server in a standard way.  Moreover, the NEW_TOKEN
   frame is not symmetrical (Clients MUST NOT send NEW_TOKEN frames)
   does not enable the support of a symmetrical control of the
   optimisation.

   The proposed solution has been proposed with QUIC standardization in
   mind, but is applicable to any transport under TLS1.3.

7.  Acknowledgements

   The authors would like to thank Gabriel Montenegro, Patrick McManus,
   Ian Swett, Igor Lubashev and Christian Huitema for their fruitful
   comments on earlier versions of this document.

8.  IANA Considerations

   TBD: text is required to register the extension BDP_metadata field.

9.  Security Considerations

   The security is provided by the 1-RTT phase.  The measure of BDP is
   made during a previous connection.  The exchange and the information
   are protected both by the TLS encryption and the NewSessionTicket
   (see section 4.6.1 of [RFC8446]).

   The BDP information the server will received is protected in the
   opaque session ticket.  The 'BDP_metadata' field is visible by the
   client only.  An client that does not trust the server transport
   adaptation ignores any session ticket associated to a 'BDP_metadata'
   field.



Kuhn, et al.               Expires May 6, 2020                  [Page 9]


Internet-Draft             Transport for 0-RTT             November 2019


   The server does not have to honour all the received requests (e.g.
   when it is resource-limited).

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

10.2.  Informative References

   [CONEXT15]
              Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short
              Flows Quickly and Safely", ACM CoNEXT , 2015.

   [I-D.ietf-quic-http]
              Bishop, M., "Hypertext Transfer Protocol Version 3
              (HTTP/3)", draft-ietf-quic-http-23 (work in progress),
              September 2019.

   [I-D.ietf-quic-recovery]
              Iyengar, J. and I. Swett, "QUIC Loss Detection and
              Congestion Control", draft-ietf-quic-recovery-23 (work in
              progress), September 2019.

   [I-D.ietf-quic-tls]
              Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
              draft-ietf-quic-tls-23 (work in progress), September 2019.

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

   [I-D.ietf-tls-ticketrequests]
              Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket
              Requests", draft-ietf-tls-ticketrequests-03 (work in
              progress), October 2019.

   [I-D.irtf-iccrg-sallantin-initial-spreading]
              Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput,
              E., and A. Beylot, "Safe increase of the TCP's Initial
              Window Using Initial Spreading", draft-irtf-iccrg-
              sallantin-initial-spreading-00 (work in progress), January
              2014.



Kuhn, et al.               Expires May 6, 2020                 [Page 10]


Internet-Draft             Transport for 0-RTT             November 2019


   [I-D.kuehlewind-quic-substrate]
              Kuehlewind, M., Sarker, Z., Fossati, T., and L. Pardue,
              "Use Cases and Requirements for QUIC as a Substrate",
              draft-kuehlewind-quic-substrate-01 (work in progress),
              July 2019.

   [I-D.pauly-quic-datagram]
              Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", draft-pauly-quic-datagram-04
              (work in progress), October 2019.

   [ICC16]    Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois,
              E., and A-L. Beylot, "Reducing web latency through TCP IW:
              Be smart", IEEE ICC , 2016.

   [ICCRG100]
              Kuhn, N., "MPTCP and BBR performance over Internet
              satellite paths", IETF ICCRG 100, 2017.

   [IJSCN19]  Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google
              QUIC performance over a public SATCOM access",
              International Journal of Satellite Communications and
              Networking , 2019.

   [NCT13]    Pirovano, A. and F. Garcia, "A new survey on improving TCP
              performances over geostationary satellite link", Network
              and Communication Technologies , 2013.

   [RFC2488]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
              Over Satellite Channels using Standard Mechanisms",
              BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
              <https://www.rfc-editor.org/info/rfc2488>.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135,
              DOI 10.17487/RFC3135, June 2001,
              <https://www.rfc-editor.org/info/rfc3135>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC6349]  Constantine, B., Forget, G., Geib, R., and R. Schrage,
              "Framework for TCP Throughput Testing", RFC 6349,
              DOI 10.17487/RFC6349, August 2011,
              <https://www.rfc-editor.org/info/rfc6349>.




Kuhn, et al.               Expires May 6, 2020                 [Page 11]


Internet-Draft             Transport for 0-RTT             November 2019


   [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
              "Increasing TCP's Initial Window", RFC 6928,
              DOI 10.17487/RFC6928, April 2013,
              <https://www.rfc-editor.org/info/rfc6928>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
              <https://www.rfc-editor.org/info/rfc7413>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Authors' Addresses

   Nicolas Kuhn (editor)
   CNES

   Email: nicolas.kuhn@cnes.fr


   Emile Stephan (editor)
   Orange

   Email: emile.stephan@orange.com


   Gorry Fairhurst (editor)
   University of Aberdeen

   Email: gorry@erg.abdn.ac.uk




















Kuhn, et al.               Expires May 6, 2020                 [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/