More details about multipath quic in Alibaba

[Yanmei Liu <[e-mail]>]

Hi everyone,

After we introduced the use cases and requirements of Multipath QUIC
project at Alibaba in the IETF Interim meeting on Oct. 22rd., we have
received many questions from people who are curious about the details in
the working group, so we would like to give more information in this
mailing list.

- Q1: Do we care about cellular cost?
- Sure. Cellular cost is a very important factor that influences our packet
scheduler design. Some of our customers are sensitive about the cellular
cost and some do not, so they need different scheduling policies. For
customers who are sensitive about cellular cost, Alibaba have collaborated
with several mobile carriers, so customers can get enrolled in a special
data plan, which allows them to enjoy unlimited free cellular data when
using apps from Alibaba eco-system(i.e. alibaba traffic costs the user
nothing). For customers who are not sensitive about the data cost, for
example, professional streamers/Vloggers and customers who want to get high
quality services for business collaborations, they can turn on the
multi-path feature if they want.

- Q2: If someone who wants this could go off an cook up an extension and
get experience with it then come back with that experience?
- We completely agree that a large-scale deployment experience is needed to
draw a conclusion and inspire new innovations. Right now, we are doing the
extension described in
https://tools.ietf.org/html/draft-an-multipath-quic-00, which is integrated
in Taobao for short-form video streaming. The feature is already made
available for certain customers in China and we are working to expand the
scope.

- Q3: How to solve the linkability problem in multipath ?
- QUICv1 solves the linkablity problem with Connection ID’s re-negotiation
when connection migration happens. We reuse the mechanism from QUICv1 in
our multipath quic implementation. For each new sub-connection, client and
server need to exchange available unused Connection IDs before a client
tries to create a new sub-connnection. When client creates a new
sub-connection and sends packets on the new path, it uses the new
Connection IDs. As the process of the negotiation is encrypted, it would
not link the packets sent on new path with the previous path.

- Q4: Difference from early multipath QUIC proposals?
- First of all, we really appreciate the work of early proposals such as
[I-D.deconinck-quic-multipath]. However, in our implementation, we’ve found
that two things are extremely important and should impact the protocol
design. First, we build multi-paths based on the concept bi-directional
“sub-connections” in each new path, and find it’s the easiest way to
implement multipath because it readily fits into the nature of both
cellular and wifi links that cover the majority of multi-path applications.
In doing so, you can almost reuse all the design / implementations for
QUICv1 connections. Second,  the multi-path QUIC design needs dynamic
scheduling strategy. As is pointed in the answer to Q1 above, our customers
who want multipath have very different needs, so making the scheduler
dynamic allows us to fulfill the job.

We would like to know what people think about the draft, and all feedbacks
and suggestions are welcome.

Thanks,
Yanmei Liu