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

Internet Engineering Task Force                             N. Kuhn, Ed.
Internet-Draft                                                      CNES
Intended status: Informational                           E. Stephan, Ed.
Expires: June 25, 2020                                            Orange
                                                       G. Fairhurst, Ed.
                                                  University of Aberdeen
                                                       December 23, 2019

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

Abstract

   QUIC 0-RTT relies on the sharing of the "initial_max_data" transport
   parameter between peers.  It indicates to the client the number of
   bytes it is allowed to send in the first packet of the 0-RTT
   connection.  This allows a faster startup of flows and enables
   adaptated buffer sizes at the server.  The traffic that the client
   sends, i.e. the egress trafic, is improved.  This memo proposes the
   sharing of additional transport parameters to provide a faster
   startup of flows and a better buffer management for the data that the
   client receives, i.e. the ingress traffic.

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 June 25, 2020.

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

Kuhn, et al.              Expires June 25, 2020                 [Page 1]
Internet-Draft             Transport for 0-RTT             December 2019

   (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
   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  BDP metadata parameters . . . . . . . . . . . . . . . . . . .   3
   4.  Extension activation  . . . . . . . . . . . . . . . . . . . .   4
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Example of server solution . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   QUIC 0-RTT relies on the sharing of the "initial_max_data" transport
   parameter between peers.  It indicates to the client the number of
   bytes it is allowed to send in the first packet of the 0-RTT
   connection.  This allows a faster startup of flows and enables
   adaptated buffer sizes at the server.  The traffic that the client
   sends, i.e. the egress trafic, is improved.  This memo proposes the
   sharing of additional transport parameters to provide a faster
   startup of flows and a better buffer management for the data that the
   client receives, i.e. the ingress traffic.

   The optimization of the time-to-service duration depends on both
   direction optimization.  QUIC may not be used for the sole use of
   HTTP3 services [I-D.ietf-quic-http], but also for symmetrical
   services.  The client device should be able to adapt to the path
   adaptation chosen by the server.  Since there are more and more
   exchange based on subscription where the server sends data first,
   with regard to ossification, it is central to dissociate the
   signalling (aka the initiator of the connection) from the peer which
   first sends application data.

   The memo focuses on cases with high Bandwidth Delay Product (BDP) and
   constrained situations (e.g. situations where buffer management at
   the client is an issue).  The extension name is 'BDP metadata'.
   Candidate transport parameters are discussed in Section 3.

Kuhn, et al.              Expires June 25, 2020                 [Page 2]
Internet-Draft             Transport for 0-RTT             December 2019

2.  Rationale

   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.

   There are cases where egress acceleration like 0-RTT early data alone
   does not improve the time-to-service.  While initial_max_data
   improves the egress time to server, the BDP metadata extension aims
   at improving ingress traffic delivery.  In some large BDP deployment
   scenarios, this can significantly improve page load time.

   There are reconnection situation where the time-to-service depends
   only on server data arrival because the service logic does not
   requires any additional information from the client.

   Currently each side has its proprietary solution to measure and to
   store path characteristics.  Having a standard way to share these
   parameters will allow the client to prepare the right resources and
   should improve the adaptation to non-default path characteristics.

   Avoid peers to compute the same path characteristics and decide
   opposed strategies: When the BDP is high the server may decide to
   increase the data on the flight while a resource-limited client will
   decide, as the ingress is expected to be slow, to reduce the
   resources.

   Having a symmetrical optimization reduces ossification.  Having the
   server to share the path characteristics avoid duplicate works and
   allows resource-limited client to save resources like CPU, memory and
   power.  Tune the default transport parameters of network paths which
   have path characteristics that increase the time-to-service.

3.  BDP metadata parameters

   Acording to [I-D.ietf-quic-transport], both endpoints store the value
   of the server transport parameters from a connection and apply them
   to any 0-RTT packets that are sent in subsequent connections to that
   peer.  Amongst the six mandatory initial parameters that section
   7.3.1 of [I-D.ietf-quic-transport] defines, only initial_max_data
   improves the time-to-service of the 0-RTT connection.  The BDP
   metadata extension augments the list of server transport parameters
   that are shared with the client to improve the time-to-service and
   save resource like CPU, memory and power.

   Parameters listed below migh be exchanged as transport parameter:

Kuhn, et al.              Expires June 25, 2020                 [Page 3]
Internet-Draft             Transport for 0-RTT             December 2019

   o  last_bytes_in_flight (0x000X): The bytes in flight measured on the
      previous connection by the server.  It is an integer in unit of
      bytes.  Using the bytes_in_flight defined in
      [I-D.ietf-quic-recovery], last_bytes_in_flight can be set to
      bytes_in_flight.

   o  last_min_rtt (0x000X): The minimum RTT measured on the previous
      connection by the server.  It is an integer in unit of
      milliseconds.  Using the min_rtt defined in
      [I-D.ietf-quic-recovery], last_min_rtt can be set to min_rtt.

   o  initial_max_pkt_number (0x000X): The maximum amount of packets
      that the server is allowed to send when reconnecting.  It is an
      integer in unit of packets.

4.  Extension activation

   Currently, in section 7.3.1 of [I-D.ietf-quic-transport], a client
   which activates 0-RTT sends back the transport parameters
   (initial_max_data ...) received from the server during the previous
   connection.

   Accept: A client which activates ingress optimization must send back
   the transport parameters of the BDP metadata extension that it
   received from the server during the previous connection.

   Tune: A client may send back a value lower than the
   initial_max_pkt_number received from the server.

   Refuse: A client which does not send back these parameters indicates
   to the server that it does not accept ingress optimisation.  A client
   which disagrees with the BDP measured by the server may refuse the
   optimization.  A limited-resource client may discard the
   optimization.

5.  Discussion

   The last_bytes_in_flight parameter is higher than the actual BDP
   since it may include bytes in buffers along the path.  The
   last_bytes_in_flight parameter is still a indication of the end-to-
   end BDP that is experienced by the congestion control.  If the
   last_bytes_in_flight is high, the server may decide to increase the
   maximum amount of packets it will send when reconnecting using the
   initial_max_pkt_number parameter.  The maximum number of initial data
   packets that can be sent without acknowledgement needs to be chosen
   to avoid congestion collapse.  An example of a server solution is
   proposed in Appendix A.  In short:

Kuhn, et al.              Expires June 25, 2020                 [Page 4]
Internet-Draft             Transport for 0-RTT             December 2019

   o  last_bytes_in_flight indicates the characteristics of the network
      underneath to both peers that can adapt their buffer sizes or
      parameter tuning.

   o  last_min_rtt lets both client and server know the minimum RTT of
      the previous connection.  Parameters can then be adapted (e.g.
      adapt how kInitialRtt is used in the "Setting the Loss Detection
      Timer" section of [I-D.ietf-quic-recovery]).

   o  initial_max_pkt_number lets the server warn the client that it may
      increase the amount of packets that it expects to send when
      reconnecting.  This value is negotiated with the client and result
      in better buffer management and reduced flow start up.

   Another paramater that could be added to the BDP metadata extension
   could be the ack_ratio.

   o  ack_ratio (0x000X): The acknowledgment ratio that has been used at
      the end of the previous connection by the server.  It is an
      integer in unit of packets.

   Starting with a high ACK ratio may induce bursts of packet in a
   potentially congested network.  That being said, keeping a low
   ack_ratio may limit performance in case of asymmetry [PANRG106].  The
   server may want to be recalled the ACK ratio that had been used at
   the end of the connection but not use it when starting the 0-RTT
   conection.

   Other parameters can contribute to the optimization of 0-RTT
   connection.  There are good candidates, like max_ack_delay, in the
   Appendix of [I-D.ietf-quic-recovery].

6.  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.

7.  IANA Considerations

   TBD: text is required to register the extension BDP_metadata field.
   Parameters are registered using the procedure defined in
   [I-D.ietf-quic-transport].

Kuhn, et al.              Expires June 25, 2020                 [Page 5]
Internet-Draft             Transport for 0-RTT             December 2019

8.  Security Considerations

   The BDP metadata parameters are measured by the server made during a
   previous connection.

   BDP extension is protected by the mechanism which protect the
   exchange of the 0-RTT transport parameters.  For the version 1 of
   QUIC, the BDP extension is protected using the mechanism which
   already protects the 'initial_max_data' parameter.  It is defined in
   sections 4.5 to 4.7 of [I-D.ietf-quic-tls].  It provides the server
   with a mean to check that the parameters proposed by the client are
   those the server sent to the client during the previous connexion.

9.  Informative References

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

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

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

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

   [PANRG106]
              Fairhurst, G., "Impact of Asymmetric Path
              Characteristics", IETF PANRG 106, 2019.

   [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>.

Kuhn, et al.              Expires June 25, 2020                 [Page 6]
Internet-Draft             Transport for 0-RTT             December 2019

Appendix A.  Example of server solution

   This section details a solution at the server to safely increase the
   maximum amount of packets that the server sends when receiving a
   0-RTT packet from a client.

   The server keeps a standard initial window to avoid adding congestion
   to a congested network.  After the reception of the acknowledgments
   for the last packet of the initial window, the server checks that the
   min_rtt is consistent.  It then adapts the congestion window to a
   higher value that must be paced out.  The initial_max_pkt_number is
   then the amount of data that the server sends during the two firsts
   RTT.

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 June 25, 2020                 [Page 7]