< draft-kuhn-quic-0rtt-bdp-02.txt   draft-kuhn-quic-0rtt-bdp-03.txt >
Internet Engineering Task Force N. Kuhn, Ed. Internet Engineering Task Force N. Kuhn, Ed.
Internet-Draft CNES Internet-Draft CNES
Intended status: Informational E. Stephan, Ed. Intended status: Informational E. Stephan, Ed.
Expires: November 22, 2019 Orange Expires: January 9, 2020 Orange
G. Fairhurst, Ed. G. Fairhurst, Ed.
University of Aberdeen University of Aberdeen
May 21, 2019 July 8, 2019
Transport parameters for 0-RTT connections Transport parameters for 0-RTT connections
draft-kuhn-quic-0rtt-bdp-02 draft-kuhn-quic-0rtt-bdp-03
Abstract Abstract
The NewSessionTicket record carries a field that tells a client the The time-to-service duration depends on both peers and the peer
volume of early data that it can include in the 0-RTT messages when initiating the connection may not be the peer actually sending data.
reconnecting to the same peer. There are cases where additional Moreover, clients may be resource-limited, behind a low bandwidth or
information can significantly improve the time-to-service. This memo a long-RTT network and may need adaptations to improve data
discusses a solution where path adaptation parameters are also shared transmission or reception. While each client and server can have its
between the peers. There are use cases where this can accelerate the dedicated solution to store path parameters, having a standard way of
throughput of subsequent 0-RTT connections in both direction. exchanging this information helps in providing symmetrical control of
the optimisation and reducing protocol ossification. QUIC may not be
limited to HTTP3: it can be used as a substrate for proxying and
tunneling.
This memo discusses a solution where the client is informed about
path parameters: both the client and the server can contribute to the
reduction of the time-to-service for subsequent connections. This
would improve symmetrical transmission of data and reduce
ossification of the protocol. To improve the time-to-service of
subsequent 0-RTT reconnection the server currently sets in the
early_data extension the maximum volume of egress data the client is
allowed to send when reconnecting. This memo proposes BDP_metadata,
an additional extension, to also inform the client about path
parameters.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. QUIC connection establishment: differences between 1-RTT and 1.1. Reducing ossification with the proposed solution . . . . 3
0-RTT connections . . . . . . . . . . . . . . . . . . . . . . 3 2. Differences between 1-RTT and 0-RTT QUIC connections
3. End-to-end solution . . . . . . . . . . . . . . . . . . . . . 3 establishment . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Description of the extension in the NewSessionTicket . . 3 3. End-to-end solution . . . . . . . . . . . . . . . . . . . . . 5
3.2. Usage of the extension in the NewSessionTicket . . . . . 4 3.1. Description of the BDP metadata extension . . . . . . . . 5
4. Best current practice . . . . . . . . . . . . . . . . . . . . 4 3.2. Usage of the extension in the NewSessionTicket . . . . . 5
5. What happens when BDP is used incorrectly? . . . . . . . . . 6 4. Best current practice . . . . . . . . . . . . . . . . . . . . 6
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. What happens when BDP is used incorrectly? . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The 0-RTT mechanism is designed to accelerate the throughput when Some network paths result in an increased time-to-service because the
establishing a connection. There are cases where 0-RTT alone does
not improve the time-to-service, and additional information can
therefore be beneficial.
Some network paths result in a reduced time-to-service because the
default parameters controlling the initialization of the transport default parameters controlling the initialization of the transport
and congestion control are not suitable for the path characteristics. and congestion control are not suitable for the path characteristics.
QUIC's congestion control is based on TCP NewReno QUIC's congestion control is based on TCP NewReno
[I-D.ietf-quic-recovery] and the recommended initial window is [I-D.ietf-quic-recovery] and the recommended initial window is
defined by [RFC6928]. A path with a large bandwidth delay product defined by [RFC6928]. A path with a large bandwidth delay product
can therefore significantly increase the time-to-service (e.g. a path can therefore significantly increase the time-to-service (e.g. a path
using satellite communication [IJSCN19] could observe a much longer using satellite communication [IJSCN19] could observe a much longer
page load time for complex pages). page load time for complex pages). The 0-RTT mechanism is designed
to accelerate the throughput when reconnecting to the same peer.
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.
This memo describes a solution where: This memo describes a solution where a BDP_metadata extension informs
the client about path parameters so that both the client and the
server can contribute to the reduction of the time-to-service:
1. the server learns a fundamental characteristic of the path during 1. the server learns characteristics of the path during a
the 1-RTT phase; connection. In most of the cases this will occur during the
first (1-RTT) connection;
2. the server sends this information to the client at the end of the 2. the server sends this information to the client at any time
1-RTT phase; during this connection after the BDP_metadata parameters are
validated;
3. the server and the client exploit the information to improve the 3. the client may discard the ticket for reasons like validation
period too short, not consistent with its own path
characteristics measure, device with limited buffer, etc.;
4. the server and the client exploit the information to improve the
time-to-service during subsequent 0-RTT connections. time-to-service during subsequent 0-RTT connections.
2. QUIC connection establishment: differences between 1-RTT and 0-RTT The proposed solution applies to TLS1.3 over any transport: even if
connections the current focus is QUIC, the solution applies, e.g., for TCP Fast
Open.
1.1. Reducing ossification with the proposed solution
While each client and server can have their dedicated solution to
store path parameters, having a standard way of exchanging this
information helps in providing symmetrical control of the
optimisation and reducing protocol ossification. This memo discusses
a solution where the client is informed about path parameters: both
the client and the server can contribute to the reduction of the
time-to-service for subsequent connections. This would improve
symmetrical transmission of data and reduce ossification of the
protocol. Some advantages of the proposed solution are the
following.
1. Provide symmetrical control of the optimisation: as extensions to
HTTP3 envision server initiated request [I-D.ietf-quic-http] the
path adaptation should be symmetrical and should not depend on
rule of the peer in the establishment. Moreover, QUIC may not be
used for the sole use of HTTP3 services but is also considered as
a relevant candidate for setting up proxies or tunnels
[I-D.kuehlewind-quic-substrate]. 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.
2. Reduce TCP-proxy and middleboxes: if both clients and servers
have the required parameters to optimize the transmissions for
different deployment scenarios, end-to-end optimization may be
proposed. As example, specific client-based adaptations can be
developed, such as adapting the ACK-ratio or increasing the
receive buffer size. Thus, deploying middleboxes that ossify the
Internet would be less relevant.
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.
2. Differences between 1-RTT and 0-RTT QUIC connections establishment
This section recalls how 1-RTT and 0-RTT operate in QUIC This section recalls how 1-RTT and 0-RTT operate in QUIC
[I-D.ietf-quic-transport]. [I-D.ietf-quic-transport].
QUIC leverages the 2 handshakes of TLS1.3 [I-D.ietf-quic-tls]: The QUIC leverages the 2 handshakes of TLS1.3 [I-D.ietf-quic-tls]: The
1-RTT handshake initiates a first set of credentials. When a 1-RTT handshake initiates a first set of credentials. When a
handshake achieves successfully, the server pushes the learned handshake achieves successfully, the server pushes the learned
information about the session to the client in an opaque session information about the session to the client in an opaque session
ticket (see section 4.6.1 of [RFC8446]). This information within the ticket (see section 4.6.1 of [RFC8446]). The information within the
opaque ticket is meaningless to the client. A client willing to opaque ticket is encrypted by the server and not readable by the
establish a fast re-opening of the session pushes back this opaque client. A session ticket can be sent at any time during the
'ticket' in a 0-RTT handshake and sends early application data. connection. The server can send several session tickets in one
connection. A client willing to establish a fast re-opening of the
session pushes back an opaque ticket in a 0-RTT handshake and sends
early application data.
In practice, the server sends the 'ticket' in a NewSessionTicket In practice, the server sends the 'ticket' in a NewSessionTicket
record [I-D.ietf-quic-tls]. The structure of the NewSessionTicket record [I-D.ietf-quic-tls]. The structure of the NewSessionTicket
includes the opaque 'ticket' and an 'extensions' field. The includes the opaque 'ticket' and an 'extensions' field. The
NewSessionTicket carries an additional field named 'early_data' that NewSessionTicket carries an additional field named 'early_data' that
indicates to the client the maximum size of application data to indicates to the client the maximum size of application data to
insert in the 0-RTT message. insert in the 0-RTT message.
3. End-to-end solution 3. End-to-end solution
This section proposes an improvement of the initialization of 0-RTT QUIC encryption of transport headers prevents the adding of
connections over high BDP networks where the client recalls, among Performance-enhancing proxy (PEP). The BDP metadata extension may be
other parameters, the BDP previously measured by the server during a substitute to PEP proxy [RFC2488], [RFC3135] when time-to-service
the 1-RTT handshake. The approach follows the tuning of the initial improvement requires acceleration of the refilling of client
window described in [I-D.irtf-iccrg-sallantin-initial-spreading] that application buffers.
has been shown to improve performance both for high BDP and more
common BDP [CONEXT15] [ICC16].
3.1. Description of the extension in the NewSessionTicket The BDP_metadata extension proposes an improvement of the
initialization of 0-RTT connections where the client recalls the BDP
metadata previously measured by the server during the 1-RTT
handshake. The approach follows the tuning of the initial window of
high BDP networks described in
[I-D.irtf-iccrg-sallantin-initial-spreading]. It has been shown to
improve performance both for high BDP and more common BDP
[CONEXT15][ICC16].
3.1. Description of the BDP metadata extension
This document defines an extension named "BDP_metadata" for the This document defines an extension named "BDP_metadata" for the
NewSessionTicket. This structure contains the following parameters: NewSessionTicket. This structure contains the following parameters:
BDP, MTU, RTT, loss-rate. BDP, MTU, RTT, loss-rate.
3.2. Usage of the extension in the NewSessionTicket 3.2. Usage of the extension in the NewSessionTicket
At the end of a 1-RTT connection, a server can send information in a 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 NewSessionTicket that describes the path to the client. The message
includes an additional 'extensions' field named 'BDP_metadata'. The includes an additional 'extensions' field named 'BDP_metadata'. The
client stores this session ticket and the 'BDP_metadata' field. client stores this session ticket and the 'BDP_metadata' field.
When the client reconnects to the same server in 0-RTT mode, it When the client reconnects to the same server in 0-RTT mode, it
pushes back this session ticket in the ClientHello and prepares pushes back this session ticket in the ClientHello and prepares
itself to receive data in the context given by the 'BDP_metadata' itself to receive data in the context given by the 'BDP_metadata'
field. (The client does not send the 'BDP_metadata' field back to field. The client does not send the 'BDP_metadata' field back to the
the server). The server receives the session ticket and extracts the server. The server receives the session ticket and extracts the BDP
BDP context. As example, it can use this message to provide context. As example, it can use this message to provide information
information that may allow the congestion controller to provide a that may allow the congestion controller to provide a throughput
throughput closer to the capacity of the path. closer to the capacity of the path.
Because the path characteristics can change over time, and may hence Because the path characteristics can change over time, and may hence
become invalid for use in a subsequent connection, the server sets become invalid for use in a subsequent connection, the server sets
the age of the ticket (see section 4.2.11.1 of [RFC8446]) to a short the age of the ticket (see section 4.2.11.1 of [RFC8446]) to a short
duration. A server could also update the ticket when the path duration. A server could also update the ticket when the path
characteristics of connection are known to have changed. characteristics of connection are known to have changed.
4. Best current practice 4. Best current practice
This section provides examples of data that could be added in the This section provides examples of data that could be added in the
skipping to change at page 6, line 47 skipping to change at page 7, line 47
| | | |
+ + + +
Figure 1: Example of opaque ticket content Figure 1: Example of opaque ticket content
5. What happens when BDP is used incorrectly? 5. What happens when BDP is used incorrectly?
This section discusses the impact of a server activating the This section discusses the impact of a server activating the
'BDP_metadata' field when the network underneath actually has a small 'BDP_metadata' field when the network underneath actually has a small
BDP. This could happen when the server BDP estimate was incorrect, BDP. This could happen when the server BDP estimate was incorrect,
client has multiple paths to choose from and uses the ticket on a when the client has multiple paths to choose from and uses the ticket
different path to which it was requested, or when the path on a different path to which it was requested, or when the path
characteristics change significantly. characteristics change significantly.
Depending on how the extension is exploited, this could result in Incorrectly exploiting the BDP_metadata could result in assigning
assigning additional resources (e.g. buffer space) that later is not additional resources (e.g. buffer space) that later is not used.
used. This could also motivate the requirement to pace the initial
window to avoid transmitting data at a too high a rate. Apart from cases where the clients are resource-limited, this is not
much of an issue.
The server could adapt the initial window to a high BDP context when
the BDP is actually small. This issue can be prevented if packets
are paced out of the server.
6. Discussion 6. Discussion
This mechanism follows the approach of the extension field This mechanism follows the approach of the extension field
'early_data' of the NewSessionTicket of TLS1.3. While 'early_data' 'early_data' of the NewSessionTicket of TLS1.3. While 'early_data'
improves the egress traffic of a client, the 'BDP_metadata' proposal improves the egress traffic of a client, the 'BDP_metadata' proposal
aims at improving ingress traffic to the client. Improving the aims at improving ingress traffic to the client. Improving the
ingress traffic can result in significant improvement to the quality- ingress traffic can result in significant improvement to the quality-
of-experience. For example, this enables the use of transport of-experience. For example, this enables the use of transport
parameters, such as the RTT, PMTU and BDP to adapt the initial data parameters, such as the RTT, PMTU and BDP to adapt the initial data
skipping to change at page 8, line 11 skipping to change at page 9, line 17
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 10.2. Informative References
[CONEXT15] [CONEXT15]
Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short Li, Q., Dong, M., and P. Godfrey, "Halfback: Running Short
Flows Quickly and Safely", ACM CoNEXT , 2015. 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-20 (work in progress),
April 2019.
[I-D.ietf-quic-recovery] [I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", draft-ietf-quic-recovery-20 (work in Congestion Control", draft-ietf-quic-recovery-20 (work in
progress), April 2019. progress), April 2019.
[I-D.ietf-quic-tls] [I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
draft-ietf-quic-tls-20 (work in progress), April 2019. draft-ietf-quic-tls-20 (work in progress), April 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-20 (work and Secure Transport", draft-ietf-quic-transport-20 (work
in progress), April 2019. in progress), April 2019.
[I-D.ietf-tls-ticketrequests] [I-D.ietf-tls-ticketrequests]
Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket
Requests", draft-ietf-tls-ticketrequests-00 (work in Requests", draft-ietf-tls-ticketrequests-01 (work in
progress), January 2019. progress), June 2019.
[I-D.irtf-iccrg-sallantin-initial-spreading] [I-D.irtf-iccrg-sallantin-initial-spreading]
Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput, Sallantin, R., Baudoin, C., Arnal, F., Dubois, E., Chaput,
E., and A. Beylot, "Safe increase of the TCP's Initial E., and A. Beylot, "Safe increase of the TCP's Initial
Window Using Initial Spreading", draft-irtf-iccrg- Window Using Initial Spreading", draft-irtf-iccrg-
sallantin-initial-spreading-00 (work in progress), January sallantin-initial-spreading-00 (work in progress), January
2014. 2014.
[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.
[ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois, [ICC16] Sallantin, R., Baudoin, C., Chaput, E., Arnal, F., Dubois,
E., and A-L. Beylot, "Reducing web latency through TCP IW: E., and A-L. Beylot, "Reducing web latency through TCP IW:
Be smart", IEEE ICC , 2016. Be smart", IEEE ICC , 2016.
[ICCRG100] [ICCRG100]
Kuhn, N., "MPTCP and BBR performance over Internet Kuhn, N., "MPTCP and BBR performance over Internet
satellite paths", IETF ICCRG 100, 2017. satellite paths", IETF ICCRG 100, 2017.
[IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google [IJSCN19] Thomas, L., Dubois, E., Kuhn, N., and E. Lochin, "Google
QUIC performance over a public SATCOM access", QUIC performance over a public SATCOM access",
 End of changes. 22 change blocks. 
66 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/