Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt

[Mirja Kuehlewind <[e-mail]>]

Hi Matt,

thanks for the feedback. Please note that in ATSSS the UE can decide to use this multipath service, or not, e.g. if the server provides multipath support directly (or even do both but not sure how useful that is). However, using the network supported service can be beneficial for downlink traffic towards the UE as the network might have information about network state and potential needs to handover. This information can be shared with the UE, however, there is no protocol mechanism to share this information with the server. I believe we briefly mention this in the draft but I guess this discussion could definitely be more explicit.

Mirja



From: QUIC <[e-mail]> on behalf of Matt Joras <[e-mail]>
Date: Tuesday, 2. June 2020 at 18:36
To: Spencer Dawkins at IETF <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt



On Tue, Jun 2, 2020 at 4:39 AM Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:
Dear QUIC,

Several of us submitted this draft (which I emphasize has no special status in IETF, 3GPP, or between IETF and 3GPP).It's being used as one of the inputs to SA2#139E, which is underway now (and that also doesn't give it any special status)..

We are, of course, interested in comments, especially if we've gotten something wrong about QUIC, directions for MP-QUIC, or apparent gaps.

The QUIC chairs have told us this is an appropriate thing to discuss on the QUIC mailing list - we did ask.
Thank you very much for producing and sharing this document, I agree it is appropriate for this forum. The diagrams in the document are especially helpful.
That being said, I have a lot of concerns about the feasibility and usefulness of the schemes in this document. I wonder if this usage of QUIC is in the spirit of many QUIC deployments, or if it potentially hinders an application's usage of QUIC. Correct me if I am wrong, but it seems one of the core tenets of these schemes is that user applications on mobile devices would have their flows to servers transparently tunneled over a multipath transport and then "untunneled" for the final transit to the server. One of the benefits of QUIC in practice is the ability to potentially bring the transport implementation "closer" to the application than was traditionally possible with TCP. One useful signal to applications is the transport's knowledge of the underlying path state. By transparently tunneling a QUIC connection over multiple paths this signal is lost. This has practical implications; the congestion controller used by the transport cannot proactively act on network switching signals, and the application cannot proactively adjust its behavior either. As a trivial example, an ABR streaming video application may detect that the underlying path has switched and subsequently adjust the bandwidth. One could imagine partially getting around this problem by implementing a channel on the UE (i.e. some sort of API) through which the information about the underlying path state is conveyed to the QUIC transport which is being tunneled. However, this doesn't address the loss of information for the server. Additionally, I would argue that if this UE informational channel exists there is no need to tunnel QUIC traffic at all -- the QUIC transport being utilized directly by the application can manage its use of the underlying network interfaces.

Said another way, I think it would be useful to further discuss why these problems need to be solved in "the network" itself rather than focusing on making QUIC "natively" capable of optimally navigating 5G networks.



Best,

Spencer, but not just Spencer
---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Sat, May 30, 2020 at 8:46 AM
Subject: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt
To: SungHoon Seo <[e-mail]<mailto:[e-mail]>>, Olivier Bonaventure <[e-mail]<mailto:[e-mail]>>, Qing An <[e-mail]<mailto:[e-mail]>>, Markus Amend <[e-mail]<mailto:[e-mail]>>, Andreas Kassler <[e-mail]<mailto:[e-mail]>>, Spencer Dawkins <[e-mail]<mailto:[e-mail]>>, Mohamed Boucadair <[e-mail]<mailto:[e-mail]>>, Quentin De Coninck <[e-mail]<mailto:[e-mail]>>, Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>, Olivier Bonaventure <[e-mail]<mailto:[e-mail]>>, Nicolas Keukeleire <[e-mail]<mailto:[e-mail]>>, Maxime Piraux <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-bonaventure-quic-atsss-overview-00.txt
has been successfully submitted by Olivier Bonaventure and posted to the
IETF repository.

Name:           draft-bonaventure-quic-atsss-overview
Revision:       00
Title:          3GPP Access Traffic Steering Switching and Splitting (ATSSS) - Overview for IETF Participants
Document date:  2020-05-30
Group:          Individual Submission
Pages:          29
URL:            https://www.ietf.org/internet-drafts/draft-bonaventure-quic-atsss-overview-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bonaventure-quic-atsss-overview/
Htmlized:       https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bonaventure-quic-atsss-overview


Abstract:
   This document briefly presents the Access Traffic Steering,
   Switching, and Splitting (ATSSS) service being specified within the
   3rd Generation Partnership Project (3GPP).  The ATSSS service
   provides network support for multihomed devices to select a path for
   transmission (steer), move traffic from one path to another (switch),
   or use multiple paths simultaneously (split).  TS 23.501 specifies an
   ATSSS architecture for TCP traffic.

   This document presents a snap-shot of the ongoing discussion in the
   3GPP to enable ATSSS for non-TCP traffic, based on the use of QUIC,
   and assesses to what extent IETF specifications can be used to meet
   the ATSSS design goals.  Apparent gaps are also documented.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


Matt Joras