Internet DRAFT - draft-kang-quic-oneway-delays-in-multipath
draft-kang-quic-oneway-delays-in-multipath
QUIC J. Kang
Internet-Draft Q. Liang
Intended status: Informational X. Fei, Ed.
Expires: 13 July 2023 Huawei
P. Liu
China Mobile
9 January 2023
Comparing One-way Delays in Multipath
draft-kang-quic-oneway-delays-in-multipath-02
Abstract
This document provides a solution for comparing one-way delays in
multipath quic. In this solution, through message interaction
between data receiver and data sender, the data sender can obtain
delay rankings of multiple specified uniflows, providing reference
for sending data packets.
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 13 July 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kang, et al. Expires 13 July 2023 [Page 1]
Internet-Draft Abbreviated Title January 2023
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
2. One-way Delays Comparation in Multipath QUIC . . . . . . . . 4
3. Protocol Extension Considerations . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Overview
QUIC basic specifications have been released successively. As an
extension of QUIC, multipath QUIC is being formulated. Currently,two
multipath QUIC suggestions ([DECONINCK-MP] and [QUIC-MP-LIU]) are
submitted to QUIC group. This document is based on [DECONINCK-MP].
[DECONINCK-MP] proposes a new design, that is, from a user
perspective, the (multipath) QUIC is a collection of unidirectional
flows ("all-uniflow"). Essentially, (multipath) QUIC consists of
multiple client-to-server uniflows and server-to-client uniflows.
When sending packets, endpoints perform data transmission scheduling
independently. Referring to [DECONINCK-MP], Figure 1 illustrates the
architecture of a multipath QUIC connection.
Kang, et al. Expires 13 July 2023 [Page 2]
Internet-Draft Abbreviated Title January 2023
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
| | | | | | | |
+-+ +-+ +-+ +-+
| | | |
| | | |
| |------CID A - Uniflow ID 1-------->| |
| | | |
| |------CID B - Uniflow ID 0-------------->|
| | | |
| |<-----CID C - Uniflow ID 0---------| |
| | | |
|<-----------CID D - Uniflow ID 1---------| |
| | | |
| |<-----CID E - Uniflow ID 2---------------|
| | | |
| | | |
| | | |
Figure 1: An Example of Uniflow Distribution over a Multipath
QUIC Connection
In single-path QUIC, RTT is valuable in adjusting packet sending
window and congestion prevention and the algorithm of RTT measurement
is depicted in the Figure 2.
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
| |
| |
T1 |-------------------Tx------------------->|-
| |
| | Delay
| |
T2 |<------------------Ty--------------------|-
| |
| RTT(Tx+Ty)=(T2-T1-Delay) |
| |
| |
Figure 2: RTT measurement Algorithm used in Single-path QUIC
In multipath QUIC scenarios, data/control packets and corresponding
ACKs are allowed to travel through different physical links to
decouple service flows (streams) and links (connections). Packets
Kang, et al. Expires 13 July 2023 [Page 3]
Internet-Draft Abbreviated Title January 2023
(including ACKs) of the same stream may be transmitted through
different connections. Therefore, minRTT, as the common path
selection and scheduling algorithm for QUIC packets cannot be
implemented effectively. So, measurement of the minimum one-way
delay or calculation of the minimum delay of multiple uniflow in
multipath QUIC protocol is important and required.
2. One-way Delays Comparation in Multipath QUIC
Figure 3 shows the algorithm presented in this document that is used
by the data sender to determine the one-way delays of each uniflow or
specified uniflows in a test period.
+---------+ +---------+
| Client | | Server |
+---------+ +---------+
| | | | | | | |
+-+ +-+ +-+ +-+
| | | |
| | | |
T1 | |-------UNICONNECTION_DELAY_REQ------->|- |-
| | (CID A, uniflow 0, Tx1) | |
| | | |
| | |D1 |
| | | |
| | | |D2
T2 | |<------UNICONNECTION_DELAY_RESP-------|- |
| | (CID B, uniflow 0, Ty1) | |
| | | |
T3 |<-------UNICONNECTION_DELAY_RESP(uniflow 1)-------|-
| | (CID c, uniflow 1, Ty2) | |
| | | |
| | | |
| |-------UNICONNECTIONS_DELAY_RESULT--------->|
| | (CID A, uniflow 1, Tx2) | |
| | | |
| | | |
| | | |
Figure 3: One-way Delays Comparation Algorithm
For example, the data sender is a server, and the data receiver is a
mobile phone client. If the server wants to obtain the one-way delay
information of each subflow, the server instructs the client to
create a measurement task and the client records the start time. The
client sends a delay test frame (UNICONNECTION_DELAY_REQ frame) to
the server through a client-to-server subflow. After receiving the
delay test frame (UNICONNECTION_DELAY_REQ frame) from the client, the
Kang, et al. Expires 13 July 2023 [Page 4]
Internet-Draft Abbreviated Title January 2023
server returns the delay measurement responses
(UNICONNECTION_DELAY_RESP frame) on all candidate server-to-client
subflows. The client records the arrival time of each delay
measurement response (UNICONNECTION_DELAY_RESP frame). Then the
client can calculate the delay rankings for these candidate server-
to-client uniflows by the formulas below:
One-way Delay(uniflow 0): Ty1 = T2-T1-D1-Tx
One-way Delay(uniflow 1): Ty2 = T3-T1-D2-Tx
If Ty1 is greater than Ty2, uniflow 0's one-way delay is greater than
that of uniflow 0. If Ty1 is less than Ty2, uniflow 0's one-way
delay is less than that of uniflow 0.
Finally, the client sends the measurement result
(UNICONNECTIONS_DELAY_RESULT frame) to the server as a reference to
select a uniflow for data transmission in this test period.
3. Protocol Extension Considerations
In this solution, three new frames are introduced to complete the
interaction of the test between endpoints:
UNICONNECTION_DELAY_REQ Frame: triggering creation of a new
measurement task sent from the data sender to the data receiver.
UNICONNECTION_DELAY_RESP Frame: delay measurement response frame sent
from the data receiver to the data sender.
UNICONNECTIONS_DELAY_RESULT Frame: measurement result releasing frame
sent from the data receiver to the data sender.
4. IANA Considerations
Request to IANA will be added later.
5. Security Considerations
Security issues will be considered later in the design.
6. References
6.1. Normative References
Kang, et al. Expires 13 July 2023 [Page 5]
Internet-Draft Abbreviated Title January 2023
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May
2021, <https://xml2rfc.tools.ietf.org/public/rfc/bibxml/
reference.RFC.9000.xml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[DECONINCK-MP]
De Coninck, Q. and O. Bonaventure, "Multipath Extensions
for QUIC (MP-QUIC)", 2021,
<https://datatracker.ietf.org/doc/draft-deconinck-quic-
multipath/>.
[QUIC-MP-LIU]
Liu, Y., Ma, Y., Huitema, C., An, Q., and Z. Li,
"Multipath Extension for QUIC",
<https://datatracker.ietf.org/doc/draft-liu-multipath-
quic/>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Jiao Kang
Huawei
Email: jiao_kang2022@163.com
Qiandeng Liang
Huawei
No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
Wuhan
China
Email: liangqiandeng@huawei.com
Kang, et al. Expires 13 July 2023 [Page 6]
Internet-Draft Abbreviated Title January 2023
XinCai Fei (editor)
Huawei
No. 410, Jianghong Road, Binjiang District
Hangzhou
China
Email: feixincai1@huawei.com
Peng Liu
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
China
Email: liupengyjy@chinamobile.com
Kang, et al. Expires 13 July 2023 [Page 7]
