RE: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]

[[e-mail]]

Dear IETF community,

as one the co-authors of the 3GPP LS request and also being active at IETF mainly in the multipath transport area, I want to share some views from my side.

ATSSS is a fantastic tool to change customer connectivity experience by simultaneously use cellular and WiFi (multi-connectivity). Hence, it promises best reliability and performance. Especially the splitting mode (per-packet multipath decision) of ATSSS gives in this context highest flexibility and highest granularity for tuning the QoE. The almost finalized Rel. 16 defines the well known and mature MPTCP, but lacks in supporting UDP and in particular its raising share of QUIC traffic.

A logical step is now to close this gap in the 3GPP Rel. 17 phase, but also improving the documentation of multipath components.
Who cannot do this better than the multipath transport experts at IETF?

In general, I see IETF in the position to well document
- Protocols
- path manager
- traffic distribution scheduler (e.g. https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00)
- re-ordering mechanism
for multipath purposes which can be simply referenced by 3GPP (ATSSS), BBF (Hybrid Access) or any other SDO.


In case QUIC is seen as the protocol of choice to fulfill the demand on the LS request, the following extensions, already considered in the QUIC WG, might be mandatory or useful

- MP support
- Datagram support for flexible reliability and latency sensitivity demands
- Tunnel/Proxying mechanism (e.g. MASQUE)

Things that might be of further interest to be investigated (e.g. at ICCRG) independent from a particular protocol
- Congestion control over congestion control (e.g. E2E QUIC over MP-QUIC or E2E QUIC over MP-DCCP)
- Encryption over encryption (e.g. QUIC over MP-QUIC over 3GPP IPsec tunnel (untrusted path))

Independent from a potential (MP-)QUIC solution, SCTP and MP-DCCP were also mentioned as candidates in this ongoing email conversation. I would say 3GPP does not necessarily expect an answer from IETF which only includes a QUIC based solution. Rather it is the believe that IETF feedbacks the solution which fits best and also considers the tough timeline of 3GPP. This might also lead to an interim solution other than QUIC, until a final QUIC solution is mature. I strongly believe that (MP-)QUIC will in future be capable of supporting every requirements of the 3GPP ATSSS LS, it's just a matter of time, which might be the crux...

I want also to point out, that the MP-DCCP framework draft with its formulated requirements (https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-mpdccp-01#section-2) most probably addresses most of the requirements of the 3GPP ATSSS LS, since it is made for ATSSS purposes (see Abstract/Introduction). Furthermore https://datatracker.ietf.org/meeting/104/materials/slides-104-tsvwg-sessb-43-markus-amend-multipath-dccp-00 might be worth reading, since it addresses the general challenges seen but also the challenges in particular using MP-QUIC (slide 3-5, 9)

BR

Markus




From: QUIC <[e-mail]> On Behalf Of Spencer Dawkins at IETF
Sent: Donnerstag, 2. April 2020 17:02
To: Martin Thomson <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: [Fwd: New Liaison Statement, "LS on need for Multi-Path QUIC for ATSSS"]

Hi, Martin, 

On Wed, Apr 1, 2020 at 10:44 PM Martin Thomson <mailto:[e-mail]> wrote:

On Thu, Apr 2, 2020, at 13:05, Spencer Dawkins at IETF wrote:
[...] 

>> If this is truly desirable, I would suggest that some of those companies listed as supporting the liaison statement could send some people to feed in requirements, refine the scope, make proposals, and work on solutions.  The IETF is unlikely to magically create something that will meet 3GPP needs and the speed of interaction via liaison statement isn't conducive to working through this.

[...]