Subject: [tsvwg] Time slot request for the new topic around MP-DCCP

From: <[email-masked]>
Date: Tue, 12 Mar 2019 11:04:13 +0000

Dear all,

I want to make you aware about three drafts, submitted recently, for enabling multipath transfer of UDP and IP traffic over multiple data paths. In particular this becomes challenging in heterogeneous networks with volatile path or access characteristics. For that reason it is a hot, respectively a not yet standardized topic in the area of Hybrid Access and also for the ongoing standardization of 3GPP Access Traffic Steering Switching Splitting (ATSSS). Hybrid access defines multi-connectivity for residential scenarios extending a traditional fixed line CPE by cellular access. ATSSS specifies multi-connectivity between a mobile device (UE) and the 5G core over cellular access and Wi-Fi. The specification for the latter can be found at http://www.3gpp.org/ftp//Specs/archive/23_series/23.793/23793-g00.zip and identifies a gap at least for transferring non-TCP traffic over multiple data paths. Since MP-TCP was agreed as an option for splitting TCP traffic within the ATSSS framework, an option for at least UDP or even IP is missing. The same also holds true for Hybrid Access, where MP-TCP is an option but does not cover the increasing share of UDP traffic, which is mainly driven by QUIC. When HTTP/3 over QUIC becomes applied, this could be the point where UDP might overtake the traditional dominating TCP in ISP networks.

In respect to multipath transmission for UDP and IP traffic

https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-framework-mpdccp/ 

proposes an IP compatible multipath architecture applicable i.a. for Hybrid Access and ATSSS, based on the MP-DCCP network protocol

https://datatracker.ietf.org/doc/draft-amend-tsvwg-multipath-dccp/

which extends the standardized DCCP protocol by multipath capabilities. MP-DCCP is an appropriate measure for serving services with no reliability demands on transportation (e.g. UDP). However, DCCP feedbacks the path conditions considered required for efficient traffic distribution schemes across volatile paths. Since the DCCP struggles with traversing todays middle-boxes (chicken-egg), U-DCCP in

https://datatracker.ietf.org/doc/draft-amend-tsvwg-dccp-udp-header-conversion/

specifies a lossless and overhead free DCCP to UDP conversion, which is more efficient than traditional encapsulation solutions.

To give you deeper insights in our motivation and the opportunity to discuss our ideas, I want to ask the tsvwg chairs for a time slot in one of the tsvwg sessions at IETF 104.

BR

Markus

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Mar 2019 11:46:11 -0700

Hi,

On 2019-3-12, at 4:04, [email-masked] wrote:
> Since the DCCP struggles with traversing todays middle-boxes (chicken-egg), U-DCCP in
> 
> https://datatracker.ietf.org/doc/draft-amend-tsvwg-dccp-udp-header-conversion/ <https://datatracker.ietf.org/doc/draft-amend-tsvwg-dccp-udp-header-conversion/>
> 

wouldn't the planned multipath support for QUIC address this use case?

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Mar 2019 15:31:37 -0700

PS - if this approach is still needed (see below), it would be useful to
address any potential interactions between UDP options and this
proposal. 

Joe

---

From: <[email-masked]>
Date: Wed, 20 Mar 2019 06:59:52 +0000

Hi Lars,

>From my understanding MP-QUIC does not support the multi-connectivity network architectures for 5G ATSSS or Hybrid Access properly.

5G ATSSS: Multi-connectivity between UE an 5G core
Hybrid Access: Multi-connectivity between CPE and ISP

>From practice, such architectures should handle IP traffic, independent of the transport protocol working on top.
I think it is obvious that MP-TCP can be applied in such architectures to split TCP streams over multiple paths, however,
that leaves the UDP, with the more and more dominating QUIC traffic, unconsidered. That is why it needs a solution on the
IP layer, e.g. a "MP-IP", or a "MP-UDP" complementary to MP-TCP.

Now returning to your question, if MP-QUIC might address above issues. QUIC and MP-QUIC can only
work end-to-end because of its encryption mechanism, which excludes any multi-connectivity architecture which requires multi-path NOT
end-to-end. Both, 5G ATSSS and Hybrid Access are NOT end-to-end, means they have to employ converter devices which transform single-path
to multi-path and vice versa. In case of 5G ATSSS, such a converter device is placed in the 5G core. The only valid implementation of MP-QUIC on
the converter device and the UE is limited to establish a QUIC tunnel between both, which is then managed by MP-QUIC.

So to summarize at this point, MP-QUIC can only be applied between the multi-connectivity termination points as a (MP-)QUIC tunnel because of QUIC's
encryption mechanism.

Just in case we would decide to go for a (MP-)QUIC tunnel architecture, which traffic should we send through? From the current perspective the QUIC transport
is mainly intended to provide a flow control with reliable in-order delivery of payload. In case we would send UDP traffic (including QUIC) piggyback through such a QUIC tunnel,
we impose flow control and encryption from the outer to the piggyback traffic.
There are tendencies to overcome QUIC's reliable nature, e.g. https://tools.ietf.org/html/draft-pauly-quic-datagram-02, however it is one thing to provide unreliable transmission
to the single path QUIC, but another to make this in MP-QUIC available, too.

MP-DCCP (https://tools.ietf.org/html/draft-amend-tsvwg-multipath-dccp-01) in combination with https://tools.ietf.org/html/draft-amend-tsvwg-multipath-framework-mpdccp-00
is able to work in any multipath architecture either end-to-end or terminated by middlebox. Furthermore it does not impose any flow control or encryption which is useless or even
disadvantageously, if the architecture aims to split IP or UDP traffic over multiple paths.

Maybe my answer overshoot your question, but I thought it's good to clarify some limitations of (MP-)QUIC in the context of multi-connectivity network architectures which are not
working ent-to-end.

BR

Markus

From: Lars Eggert <[email-masked]>
Sent: Dienstag, 12. März 2019 19:46
To: Amend, Markus <[email-masked]>
Cc: [email-masked]
Subject: ***CAUTION_Invalid_Signature*** Re: [tsvwg] Time slot request for the new topic around MP-DCCP

Hi,

On 2019-3-12, at 4:04, [email-masked]<mailto:[email-masked]> wrote:

Lars

---

From: <[email-masked]>
Date: Wed, 20 Mar 2019 07:28:31 +0000

Hi Joe,

since I’m not fully aware of what you mean, it would great if you could point me to the right direction.

BR
Markus

From: Joe Touch <[email-masked]>
Sent: Dienstag, 12. März 2019 23:32
To: Lars Eggert <[email-masked]>
Cc: Amend, Markus <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] Time slot request for the new topic around MP-DCCP

PS - if this approach is still needed (see below), it would be useful to address any potential interactions between UDP options and this proposal.

Joe

Lars