Re: [tsvwg] ***CAUTION_Invalid_Signature*** Re: Time slot request for the new topic around MP-DCCP

[<[e-mail]>]

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 <[e-mail]>
Sent: Dienstag, 12. März 2019 19:46
To: Amend, Markus <[e-mail]>
Cc: [e-mail]
Subject: ***CAUTION_Invalid_Signature*** Re: [tsvwg] Time slot request for the new topic around MP-DCCP

Hi,

On 2019-3-12, at 4:04, [e-mail]<mailto:[e-mail]> 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/

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

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

Lars