< draft-kuhn-quic-0rtt-bdp-00.txt   draft-kuhn-quic-0rtt-bdp-01.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: September 6, 2019 Orange Expires: September 12, 2019 Orange
March 5, 2019 March 11, 2019
Transport parameters for 0-RTT connections Transport parameters for 0-RTT connections
draft-kuhn-quic-0rtt-bdp-00 draft-kuhn-quic-0rtt-bdp-01
Abstract Abstract
0-RTT is designed to accelerate the throughput at the establishment 0-RTT is designed to accelerate the egress throughput at the
of a connection. There are cases where 0-RTT alone does not improve establishment of a connection. There are cases where 0-RTT alone
the time-to-service. does not improve the time-to-service.
This memo discusses a solution where a fundamental characteristic of This memo discusses a solution where a fundamental characteristic of
the path is learned during the 1-RTT phase and shared with the 0-RTT the path is learned during the 1-RTT phase and shared with the 0-RTT
phase to accelerate the initial throughput during subsequent 0-RTT phase to accelerate the initial throughput during subsequent 0-RTT
connections. connections.
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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 6, 2019. This Internet-Draft will expire on September 12, 2019.
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 . . . . . . . . . . . . . . . . 2 2. QUIC connection establishment . . . . . . . . . . . . . . . . 3
3. Large BDP connections . . . . . . . . . . . . . . . . . . . . 3 3. Large BDP connections . . . . . . . . . . . . . . . . . . . . 3
4. TCP split solution . . . . . . . . . . . . . . . . . . . . . 4 4. TCP split solution . . . . . . . . . . . . . . . . . . . . . 4
5. End-to-end solution . . . . . . . . . . . . . . . . . . . . . 4 5. End-to-end solution . . . . . . . . . . . . . . . . . . . . . 4
5.1. Description of the extension in the NewSessionTicket . . 4 5.1. Description of the extension in the NewSessionTicket . . 4
5.2. Usage of the extension in the NewSessionTicket . . . . . 5 5.2. Usage of the extension in the NewSessionTicket . . . . . 5
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Best current practice . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 6 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 6 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
0-RTT is designed to accelerate the throughput at the establishment 0-RTT is designed to accelerate the throughput at the establishment
of a connection. There are cases where 0-RTT alone does not improve of a connection. There are cases where 0-RTT alone does not improve
the time-to-service. the time-to-service.
As shown in [IJSCN19], the usage of a congestion control and As shown in [IJSCN19], the usage of a congestion control and
transport initialization not adapted to satellite communication transport initialization not adapted to satellite communication
results in higher page loading time for heavy pages in a SATCOM results in higher page loading time for heavy pages in a SATCOM
skipping to change at page 3, line 31 skipping to change at page 3, line 35
3. Large BDP connections 3. Large BDP connections
GEO-satellite based systems characteristics differ from terrestrial GEO-satellite based systems characteristics differ from terrestrial
networks with: networks with:
o A large propagation delay of at least 250ms one-way delay; o A large propagation delay of at least 250ms one-way delay;
o A high bit-rate in case of mobile users or when a user connects o A high bit-rate in case of mobile users or when a user connects
behind a box using Wi-Fi; behind a box using Wi-Fi;
o Highl asymmetric links. o Highly asymmetric links.
These characteristics have an impact on end-to-end congestion These characteristics have an impact on end-to-end congestion
controls: controls:
o Transport initialization: the 3-way handshake takes a long time o Transport initialization: the 3-way handshake takes a long time
reducing the time at which actual data can be transmitted; reducing the time at which actual data can be transmitted;
o Maximum windows sizing: to fully exploit the bottleneck capacity, o Maximum windows sizing: to fully exploit the bottleneck capacity,
the high BDP may induce an important number of in-flights packets; the high BDP may induce an important number of in-flights packets;
skipping to change at page 4, line 11 skipping to change at page 4, line 11
o Getting up to speed: the exponential increase of the data rate o Getting up to speed: the exponential increase of the data rate
transmission for a channel capacity probing is slowed down when transmission for a channel capacity probing is slowed down when
the RTT is high. the RTT is high.
4. TCP split solution 4. TCP split solution
High BDP networks commonly break the TCP end-to-end paradigm to adapt High BDP networks commonly break the TCP end-to-end paradigm to adapt
the transport protocol. Splitting TCP allows adaptations to this the transport protocol. Splitting TCP allows adaptations to this
specific use-case and assessing the issues discussed in section specific use-case and assessing the issues discussed in section
Section 3. PEP [RFC3135] are commonly deployed in SATCOM Section 3. PEP [RFC3135] are commonly deployed in SATCOM
infrastructure for that purpose and their deployment results in lower infrastructure for that purpose and their deployment can result in
page load times [ICCRG100] in a SATCOM use-case. 50% page load time reduction in a SATCOM use-case [ICCRG100].
[NCT13] and [RFC3135] describe the main functionalities of SATCOM TCP [NCT13] and [RFC3135] describe the main functionalities of SATCOM TCP
split solutions. Shortly, for traffic going from a gateway to an end split solutions. Shortly, for traffic going from a gateway to an end
user behind a terminal, the TCP split intercepts TCP SYN to act as user behind a terminal, the TCP split intercepts TCP SYN to act as
the end user and adapt the data rate transmission to the SATCOM the end user and adapt the data rate transmission to the SATCOM
scenario. The TCP split specifically tune the TCP parameters to the scenario. The TCP split specifically tune the TCP parameters to the
context (latency, available capacity) that is measured. context (latency, available capacity) that is measured.
One important advantage of a TCP split solution is that it does not One important advantage of a TCP split solution is that it does not
require any end-to-end modifications and is independent for both require any end-to-end modifications and is independent for both
skipping to change at page 4, line 40 skipping to change at page 4, line 40
connections over satellite communication where the client recalls the connections over satellite communication where the client recalls the
BDP previously measured by the server during the 1-RTT handshake. BDP previously measured by the server during the 1-RTT handshake.
The approach follows the tuning of the initial window described in The approach follows the tuning of the initial window described in
[I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to [I-D.irtf-iccrg-sallantin-initial-spreading] which has been shown to
improve performance both for high BDP and more common BDP improve performance both for high BDP and more common BDP
[CONEXT15][ICC16]. [CONEXT15][ICC16].
5.1. Description of the extension in the NewSessionTicket 5.1. Description of the extension in the NewSessionTicket
A new extension named "BDP_data" is defined for NewSessionTicket. It A new extension named "BDP_data" is defined for NewSessionTicket. It
contains the following value: BDP_value, that is the value in in bits contains the following value: BDP_value, that is the value in bits
per second (same unit as [RFC6349]). The reception of the field (same unit as [RFC6349]). The reception of the field BDP_data
BDP_data provides the client with 3 indications: provides the client with 3 indications:
o The path with this server has a large BDP; o The path with this server has a large BDP;
o The server added the path characteristics in the opaque 'ticket' o The server added the path characteristics in the opaque 'ticket'
field; field;
o The server will optimize the reopening of the session upon o The server will optimize the reopening of the session upon
reception of this opaque ticket. reception of this opaque ticket.
5.2. Usage of the extension in the NewSessionTicket 5.2. Usage of the extension in the NewSessionTicket
skipping to change at page 5, line 26 skipping to change at page 5, line 26
does not send the 'BDP_data' field back to the server). The server does not send the 'BDP_data' field back to the server). The server
receives the session ticket and extracts the BDP context. It uses receives the session ticket and extracts the BDP context. It uses
this information to provide a throughput closer to the capacity of this information to provide a throughput closer to the capacity of
the path. the path.
As the validity of the path characteristics may change over the time As the validity of the path characteristics may change over the time
the server sets the age of the ticket (see section 4.2.11.1 of the server sets the age of the ticket (see section 4.2.11.1 of
[RFC8446]) to a short duration or updates the ticket when the path [RFC8446]) to a short duration or updates the ticket when the path
characteristics of the current connection changes. characteristics of the current connection changes.
6. Discussion 6. Best current practice
This section provides examples of data that could be added in the
opaque 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 it is
opaque to the client. The presence of the "BDP_data" extension field
in the NewSessionTicket informs the client that the server will
actively take action to improve its throughput when the session will
restart.
Here are examples of 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 client aware of the high BDP: The 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". On top of other transport parameters used by
the server, knowing that the BDP is high let the client adapt
parameters specifically. As example, the client could adapt the
ACK ratio following the discussion in Issue 1978 of the GITHUB
repository.
o PMTU: The knowledge of the MTU of the 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 the
previous connection RTT improves the throughput because the server
can safely improve the slow start: e.g. using pacing models of
[I-D.irtf-iccrg-sallantin-initial-spreading] can result in high IW
for high RTT paths and a common 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 later; as an example
it reduces the validity to one day.
CLIENT SERVER
+-----------------------------------+
| 1 RTT connection |
+--+------------------------------+-+
| |
+<---1-RTT TLS1.3 HANDSHAKE--->+
| | +------------+
+<-----data transmission------>+ |path charact|
| | |record |
| | +------------+
|<-------------NewSessionTicket+
Client aware | +ticket_lifetime |
of high BDP | +'opaque' field |
path | + ... |
| + PMTU |
| + connection RTT |
| +'extension' field |
| + early_data |
| + BDP_data |
| |
+-----------------------------------+
| 0 RTT connection |
+-----------------------------------+
| |
+ClientHello------------------>|
|+'opaque' field | +-------------------+
| + ... | |param adaptation |
| + PMTU | |e.g. |
| + connection RTT | |tuned and paced IW |
| | +-------------------+
| |
+<----+data transmission+----->+
| |
+ +
Figure 1: Example of opaque ticket content
7. Discussion
The proposal made in this draft follows the approach of the extension The proposal made in this draft follows the approach of the extension
field 'early_data' of the NewSessionTicket of TLS1.3. Deeper field 'early_data' of the NewSessionTicket of TLS1.3. While
adaptations of the QUIC congestion control can improve the end-user 'early_data' improves the egress traffic of a client, the 'BDP_data'
experience in high BDP contexts but proposing it for other contexts proposal aims at improving its ingress traffic. Improving the
may not be relevant. Indeed, designing either the data-center or the ingress traffic of an end user can result in drastic quality-of-
end-user stacks based on large BDP constraints can hardly be done if experience improvements. As example, this contribution enables the
the deployment is not dedicated to this context (such as it would be exploitation of the RTT, PMTU and BDP to adapt the initial data
the case with specific CDN). Adapting a generic data-center may not transmission of a 0-RTT connection to halve the page load time of a
be viable since it may result in too aggressive behavior for more web page download.
common BDP. Moreover, at the end-user side, adapting the stacks or
the browser has been proposed in the past but the maintenance is
complexed since web browsers' versions often change.
7. Acknowledgements 8. Acknowledgements
None. None.
8. Contributors 9. Contributors
None. None.
9. IANA Considerations 10. IANA Considerations
TBD: text is required to register the extension BDP_data field. TBD: text is required to register the extension BDP_data field.
10. Security Considerations 11. Security Considerations
The security is provided by the 1-RTT phase. The measure of BDP is The security is provided by the 1-RTT phase. The measure of BDP is
made during a previous connection. The exchange and the information made during a previous connection. The exchange and the information
are protected both by the TLS encryption and the NewSessionTicket are protected both by the TLS encryption and the NewSessionTicket
(see section 4.6.1 of [RFC8446]). (see section 4.6.1 of [RFC8446]).
The BDP information the server will received is protected in the The BDP information the server will received is protected in the
opaque session ticket. The 'BDP_data' field is visible by the client opaque session ticket. The 'BDP_data' field is visible by the client
only. An client which does not trust the server transport adaptation only. An client which does not trust the server transport adaptation
ignores any session ticket associated to a 'BDP_data' field. ignores any session ticket associated to a 'BDP_data' field.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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>.
11.2. Informative References 12.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-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-18 (work in Congestion Control", draft-ietf-quic-recovery-18 (work in
progress), January 2019. progress), January 2019.
 End of changes. 18 change blocks. 
42 lines changed or deleted 120 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/