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
