Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Nicolas Kuhn , Stephan Emile , Gorry Fairhurst
Last updated 2019-12-17 (Latest revision 2019-11-04)
Replaced by draft-kuhn-quic-careful-resume, draft-kuhn-quic-careful-resume
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kuhn-quic-0rtt-bdp-05
Internet Engineering Task Force                             N. Kuhn, Ed.
Internet-Draft                                                      CNES
Intended status: Informational                           E. Stephan, Ed.
Expires: June 19, 2020                                            Orange
                                                       G. Fairhurst, Ed.
                                                  University of Aberdeen
                                                       December 17, 2019

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

Abstract

   QUIC 0-RTT enables the optimization of the egress traffic.  It relies
   on the sharing of the "initial_max_data" transport parameter between
   peer consent.  This memo proposes the sharing of additional transport
   parameters to optimize 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 19, 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
   (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

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

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  BDP metadata parameters . . . . . . . . . . . . . . . . . . .   3
   4.  Extension activation  . . . . . . . . . . . . . . . . . . . .   4
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   QUIC 0-RTT enables the optimization of the egress traffic.  It 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 sent when reconnecting.

   This memo proposes the sharing of additional transport parameters to
   optimize the ingress traffic exchange at both ends.  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, 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.  The extension name is 'BDP metadata'.
   Candidate transport parameters are discussed in Section 3.

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

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

   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 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:

   o  last_bdp (0x000X): The last_bdp parameter is the BDP measured on
      the previous connection by the server.  It is an integer in unit
      of bytes.  Using the min_rtt and congestion_window defined in
      [I-D.ietf-quic-recovery], last_bdp can be set to
      min_rtt*congestion_window.

   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.

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

   When a server measures a large BDP, it may decide to increase the
   maximum amount of packets it will send when reconnecting.  This
   enables a client which accepts the optimization to adjust its buffers
   at reconnection time.

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

   Other parameters can contribute to the optimization of 0-RTT
   connection.

   There are good candidates, like min_rtt, in the Appendix of
   [I-D.ietf-quic-recovery].

   Field measurements showed that tuning the ACK ratio improves the
   performance of asymmetrical exchange [PANRG106].

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 19, 2020                 [Page 4]
Internet-Draft             Transport for 0-RTT             December 2019

8.  Security Considerations

   The security is provided by the 1-RTT phase.  The measure of BDP is
   made during a previous connection.

9.  Informative References

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

Authors' Addresses

   Nicolas Kuhn (editor)
   CNES

   Email: nicolas.kuhn@cnes.fr

   Emile Stephan (editor)
   Orange

   Email: emile.stephan@orange.com

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

   Gorry Fairhurst (editor)
   University of Aberdeen

   Email: gorry@erg.abdn.ac.uk

Kuhn, et al.              Expires June 19, 2020                 [Page 6]