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]