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

[Olivier Bonaventure <[e-mail]>]

Matt,
> 
> 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. 

This ATSSS solution should be considered as another application for QUIC 
that leverages the flexibility of QUIC. With the datagram extension, it 
becomes possible to carry unreliable datagrams over a 
congestion-controlled QUIC connection to the ATSSS function that is 
provided by the network operator. This could be considered as a kind of 
operator-provided "VPN" service that allows unmodified applications 
running on enduser devices to efficiently use the available paths 
without having to modify these applications.

> 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.

Solving these problems in the network allows to support existing and 
unmodifed applications, which is a key requirement from a deployment 
viewpoint. A longer term approach could be to expose more information 
from the underlying network to the upper layer so that new applications 
can make informed and possibly better choices.


Olivier