Technical Report Implementation of Single Packet Number Space in Multi-Path QUIC

2025-05-06 0 0 587.85KB 6 页 10玖币

侵权投诉

Technical Report: Implementation of Single Packet Number

Space in Multi-Path QUIC

Yingqi Tang, Yunfei Ma, Yanmei Liu

Alibaba Group

ABSTRACT

Over the past few of years, we have witnessed increasing inter-

ests in the use cases of multipath QUIC from both industry and

academia [

–

]. For example, Alibaba deployed XLINK [

], a QoE-

driven multipath QUIC solution, in Taobao short video and showed

benets in both reduced tail latency and video rebuering. For

the time being, the multipath QUIC protocol is in the process of

standardization at the IETF QUIC working group, with the draft re-

cently updated to version 02 [

]. The focus of the draft is to provide

basic guidance on the implementation so that we can encourage

more exploration, testing, and nally, an accelerated adoption of

this technology. However, draft-02 has brought up an open issue

on whether the multipath QUIC should be implemented using sin-

gle packet number space (SPNS) or multiple packet number space

(MPNS), as in the current draft, both options co-exist.

Knowing that one cannot draw a solid conclusion without ex-

periments, we implement both SPNS and MPNS at Alibaba and

measured their performance. The goal is to help the community

better understand the implication, and we hope this report can be

a useful resource for engineers and researchers who are interested

in deploying multipath QUIC. We also suggest readers to read [

which is another comparative study between MPNS and SPNS based

on Picoquic [5].

1 INTRODUCTION

We assume the reader is familar with QUIC. For the backgroud

knowledge, please refer to RFC9000 [

]. There is also a fantastic

blog [

] by Lucas Pardue on this topic that we encourage readers

to read. Our today’s discussion will be on SPNS vs. MPNS. So what

are they?

SPNS:

Single Packet Number Space (SPNS) means that in multipath

QUIC, packets transmitted on dierent paths will be assigned packet

numbers from the same packet number space. For example, if packet

number #1 is assigned to a packet on the rst path, the same number

(i.e., #1) cannot be assigned to a packet on another path. In other

words, packet number overlapping is not allowed.

MPNS:

Multiple Packet Number Space (MPNS) means that in

multipath QUIC, packet numbers are assigned based on a per-path

manner, and packets on dierent paths use separate packet number

spaces. For example, two paths can both number their packets with

the number #1,#2, and #3. Packet number overlapping is perfectly

ne.

There are pros and cons in each option. For SPNS, the benets

include: (1) it does not require any change in how the nonce is

computed for AEAD; (2) it allows multi-path transport even when

zero-CID is used. The drawbacks of SPNS include: (1) it cannot

straightforwardly use the algorithms in RFC9002 [

] for loss detec-

tion, RTT sampling, and recovery; (2) the packet ACK size is larger

due to increased number of holes in the packet range records, and

(3) there is a lack of ECN support.

For MPNS, the benets include: (1) the loss detection and recov-

ery are more straightforward and easy to implement; (2) the ACK

size is not bloated as the packet number is continuous on each path;

(3) supporting ECN is easy with path identiers. The drawbacks of

MPNS are: (1) it requires the change of how we compute the nonce;

(2) it needs the CID to identify each path, and thus, MPNS does not

work with zero-CID cases.

Indeed, the qualitative properties such as the nonce modication,

the support of zero-CID cases, and the support of per-path ECN

are easy to reach concensus among the working group. However,

questions like the implementation complexity and performance

tradeo typically do not have a yes-or-no answer without further

experiments and real-world deployments.

Based on the draft-ietf-quic-multipath-01 [

], we implement

multipath QUIC for both SPNS and MPNS. An endpoint can decide

whether to use single path, multipath with MPNS or multipath with

SPNS through the negotiation with a peer. For SPNS, we highlight

the algorithm changes required for both sender and receiver to

maintain performance, including how to obtain accurate and timely

RTT estimations. Our implementation is based on XQUIC [

], an

open source QUIC library in C language developed by Alibaba

Group.

Our experiement consists of two parts: (1) controlled experi-

ment with Mahi-mahi mpshell emulation tools and (2) a large-scale

A/B test in Taobao RPC over HTTP scenario with over 1.5 million

request samples. In this typical scenario, our results showed that

SPNS had a slight performance degradation of less than 1% on av-

erage request completion time compared with that of MPNS. We

observed that its impact on the request completion time for small-

sized RPC requests was not signicant. However, SPNS became

slower than MPNS when the request size was large. In terms of the

acknowledgement cost, if not constrained, the average size of ACK

frame of SPNS could go 50% higher than that of MPNS.

We tried to reduce the ACK frame size of SPNS using strategies

discussed on the WG draft’s Github [

]. Our results showed that

we were able to bring down average ACK frame size of SPNS by

40%. However, in doing so, we observed decrease in transmission

eciency.

2 SINGLE PACKET NUMBER SPACE

Conceptually, a packet number space is the context in which a

packet can be processed and acknowledged. For single path QUIC,

the packet numbers in one space forms a continuous sequence start-

ing from 0. Such a continuity simplies algorithms like loss recovery

and RTT measurements. However, this assumption is no longer

valid in multipath QUIC using SPNS. Fig. 1 illustrates a possible

scenario. There are two paths in the connection: Path 0 and Path 1.

arXiv:2210.13663v1 [cs.NI] 24 Oct 2022

76 15141312111098

6543210

151413

1211

1098

ACK

(10-8, 6-0)

Path 0

Path 1

SenderReceiver

unack_queue

receive_record

Figure 1: Sending and receiving data in SPNS.

76 151413121110986543210

1514

1211

1098

ACK

(13, 10-0)

Path 0

Path 1 SenderReceiver

unack_queue

receive_record ACK

(7-0)

Figure 2: Write ACK frame based on the largest received packet of

the path.

The sender has sent packets with packet numbers

{

}

at Path 0 and

{

}

at Path 1. The receiver has

received packets

{

}

at Path 0 and

{

}

at Path 1.

What ends up happening is that the packet numbers are spread

across multiple paths, which yields a discontinuous sequence on

each path. Such a discontinuity leads to multiple problems:

•

Packets reordering. Due to heterogeneity of dierent paths, the

packets may arrive out of order. The reordering leaves holes in

the received packet number record and causes ACK range to

bloat. If the number of ACK ranges is larger than the maximum

count specied by the endpoint, some of them cannot be sent,

which causes a sender to incorrectly consider packets loss, even

though they have been actually delivered.

•

Change in the loss detection algorithm. Due to the packet num-

ber discontinuity, the sender needs to maintain an association

between sent packet numbers and the path over which these

packets were sent, for the purpose of loss detection and con-

gestion control. This introduces additional complexity in the

implementation.

•

Change in the RTT estimation algorithm. An RTT sample in SPNS

may be the sum of the uplink delay of one path and downlink

delay of another path. In the current WG draft, it is undened

how this RTT sample should be used to compute the smoothed

round-trip time estimation. On the other hand, it is dicult to

control the RTT update frequency of each path, which requires

the receiver to design specic strategies.

Next, we discuss how we implement SPNS’s loss detection and

RTT measurment algorithms.

2.1 Loss Detection

Regarding the loss detection, we followed the basic strategies that

has been dened in the current working group draft for SPNS,

including:

•

Maintain Packet Context. The sender stores an index association

between each path and the packets it sends.

•

Loss Detection. In single path QUIC, an unacknowledged packet

is declared lost if it was sent kPacketThreshold packets before

an acknowledged packet, or it was sent long enough in the past.

Instead of simply using (largest acknowledged PN - kPacket-

Threshold) , we track the sending history of a path to determine

which packet was the k-th one before the largest acknowledged

packet in the same path.

2.2 RTT Estimation

According to QUIC RFC9002 [

], an endpoint generates an RTT

sample on receiving an ACK frame that meets the following two

conditions:

•

the largest acknowledged packet number is newly acknowledged,

and

•

at least one of the newly acknowledged packets was ack-eliciting.

The RTT sample,

𝑙𝑎𝑡𝑒𝑠𝑡_𝑟𝑡𝑡

, is generated as the time elapsed

since the largest acknowledged packet was sent:

𝑙𝑎𝑡𝑒𝑠𝑡_𝑟𝑡𝑡 =𝑎𝑐𝑘_𝑡𝑖𝑚𝑒 -𝑠𝑒𝑛𝑑_𝑡𝑖𝑚𝑒_𝑜 𝑓 _𝑙𝑎𝑟𝑔𝑒𝑠𝑡_𝑎𝑐𝑘𝑒𝑑

However, when applying the above algorithm, we encountered

the following problems:

•RTT of some paths are not updated timely.

According to

draft-ietf-quic-ack-frequency [

], the receiver should send an

ACK after receiving ack-eliciting-threshold number packets and

an ack-eliciting packet must be acknowledged within MAX_ACK

_DELAY. For example, one maintains an ack-eliciting threshold

of two and an ACK timer in the connection layer, and pushes

the packet into the sending queue after writing ACK frame. The

sending path of an ACK packet is not decided before it is actually

sent. As a consequence, transmission frequency of ACK on each

path is later decided by the multi-path scheduling algorithm. In

particular, the number of ACK packets sent by each path was

evenly distributed when using Round Robin scheduling, but when

using minRTT scheduler, all of the ACKs are sent from the path

of shorter delay, which is not useful to the RTT update for other

paths.

Our solution:

Therefore, we specify that the receiver should send

back an ACK on the same path which has just received two

ack-eliciting packets. In this way, the ACK frequency of a path

depends on its received packet count rather than the specic

path scheduling algorithm.

•ACK frames depend on the largest received packet of the

connection, not the path.

According to RFC9002 [

], the ack

range in an ACK frame should start from the largest packet

number received in the packet number space and the "ACK delay"

eld is lled in the time dierence between the ACK writing

time and the receiving time of the largest received packet. The

sender should generate an RTT sample for a path when an ACK

is received at that path and the RTT sample conditions are met.

There are two problems with this scheme in practice:

–

The created RTT sample may be the sum of the uplink delay

of a path and the downlink delay of another path, resulting in

inaccurate path RTT estimation. There may be inherent delay

dierence between paths, leading to the fact that almost all

the largest received packets in the ACKs were sent by the path

with shortest delay.

–

On the other hand, even if the receiver sends ACKs evenly on

each path, an ACK packet #0 sent rst from Path 0 may arrive

later than the ACK packet #1 sent after from Path 1, because

the delay of Path 0 is larger than that of Path 1. Once the ACK

packet #1 of Path 1 is received and processed to generate an

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

TechnicalReport:ImplementationofSinglePacketNumberSpaceinMulti-PathQUICYingqiTang,YunfeiMa,YanmeiLiuAlibabaGroupABSTRACTOverthepastfewofyears,wehavewitnessedincreasinginter-estsintheusecasesofmultipathQUICfrombothindustryandacademia[1–3].Forexample,AlibabadeployedXLINK[1],aQoE-drivenmultipathQUICsol...

展开>> 收起<<

Technical Report Implementation of Single Packet Number Space in Multi-Path QUIC.pdf

共6页,预览2页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Technical Report Implementation of Single Packet Number Space in Multi-Path QUIC

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: