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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 2 Jun 2020 06:38:55 -0500

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.

Best,

Spencer, but not just Spencer

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

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.

The IETF Secretariat

---

From: Matt Joras <[email-masked]>
Date: Tue, 2 Jun 2020 09:34:14 -0700

On Tue, Jun 2, 2020 at 4:39 AM Spencer Dawkins at IETF <
[email-masked]> 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)..
>
> 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.

> until the htmlized version and diff are available at tools.ietf.org.
Matt Joras

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 2 Jun 2020 19:44:53 +0000

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 <[email-masked]> on behalf of Matt Joras <[email-masked]>
Date: Tuesday, 2. June 2020 at 18:36
To: Spencer Dawkins at IETF <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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,

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

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:

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 13:21:10 -0700

I think that we should be very clear that the primary goal for QUIC
multipath design is end-to-end. For example, a device might very well
have connection with 2 cellular networks, each providing their own
"advanced" services, and use end-to-end multipath to balance traffic
between the two networks.

We also have to consider multipath privacy. In the ATSSS setup, the
device is supposed to establish a connection with the mobile operator's
service even in cases when it is only connected to a Wi-Fi network. That
means disclosing connectivity and activity to the operator, just in case
a backup through cellular might be needed. This is definitely a
trade-off that many applications will not want to make. End to end
multipath alleviates that concern, because the network operators only
learn of the device's activity when the devices actually uses their network.

-- Christian Huitema

On 6/2/2020 12:44 PM, Mirja Kuehlewind wrote:
>
> 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 <[email-masked]> on behalf of Matt Joras
> <[email-masked]>
> *Date: *Tuesday, 2. June 2020 at 18:36
> *To: *Spencer Dawkins at IETF <[email-masked]>
> *Cc: *IETF QUIC WG <[email-masked]>
> *Subject: *Re: New Version Notification for
> On Tue, Jun 2, 2020 at 4:39 AM Spencer Dawkins at IETF
> <[email-masked] <mailto:[email-masked]>>
> 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.
>
> 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,
>
>      
>
>     From: <[email-masked] <mailto:[email-masked]>>
>     To: SungHoon Seo <[email-masked] <mailto:[email-masked]>>, Olivier
>     Bonaventure <[email-masked]
>     <mailto:[email-masked]>>, Qing An
>     <[email-masked] <mailto:[email-masked]>>,
>     Markus Amend <[email-masked]
>     <mailto:[email-masked]>>, Andreas Kassler
>     <[email-masked] <mailto:[email-masked]>>, Spencer
>     Dawkins <[email-masked]
>     <mailto:[email-masked]>>, Mohamed Boucadair
>     <[email-masked]
>     <mailto:[email-masked]>>, Quentin De Coninck
>     <[email-masked]
>     <mailto:[email-masked]>>, Mirja Kuehlewind
>     <[email-masked]
>     <mailto:[email-masked]>>, Olivier Bonaventure
>     <[email-masked]
>     <mailto:[email-masked]>>, Nicolas Keukeleire
>     <[email-masked]
>     <mailto:[email-masked]>>, Maxime Piraux
>     <[email-masked] <mailto:[email-masked]>>
>
>
>
>
>     Title:          3GPP Access Traffic Steering Switching and
>     Splitting (ATSSS) - Overview for IETF Participants
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>  
>
> Matt Joras
>

---

From: Roland Zink <[email-masked]>
Date: Wed, 3 Jun 2020 00:19:08 +0200

Hi Christian,

When I understood this right for MPTCP then this can be applied 
end-to-end without any ATSSS interaction. The ATSSS proxy is only needed 
when the end servers do not support MPTCP. When there is end-to-end 
MPQUIC then there doesn't seem to be a need for ATSSS as well.

A cellular network often knows something about mobile devices even when 
those devices are not actively using it. A device registers with a 
cellular network and gets an IP address. After that the cellular network 
keeps track of the device location area (only an area, not the exact 
location) even when the device is inactive or connected to WiFi. This is 
done in case some data destinated to the device (IP) arrives in the 
cellular network (PGW/UPF). Then the device is paged in the area and the 
data is delivered after the device becomes active. You can of cause turn 
off cellular if you don't want this.

Regards,

Roland

Am 02.06.2020 um 22:21 schrieb Christian Huitema:
> device is supposed to establish a connection with the mobile 
> operator's service even in cases when it is only connected to a Wi-Fi 
> network. That means disclosing connectivity and activity to the 
> operator, just in case a backup through cellular might be needed. This 
> is definitely a trade-off that many applications will not want to 
> make. End to end multipath alleviates that concern, because the 
> network operators only learn of the device's activity when the devices 
> actually uses their network.
>
> -- Christian Huitema
>
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Dear QUIC,
>>
>>     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)..
>>
>> 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 
>> 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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 16:00:12 -0700

On 6/2/2020 3:19 PM, Roland Zink wrote:
> end-to-end without any ATSSS interaction. The ATSSS proxy is only
> needed when the end servers do not support MPTCP. When there is
> end-to-end MPQUIC then there doesn't seem to be a need for ATSSS as well.
>
Yes, that's pretty much the idea. In fact, we have seen arguments on the
QUIC WG list that the scenarios in which multipath is used for
reliability are already supported with the connection migration features
of QUIC  V1. It is not clear that there is a technical need for ATSSS
style proxies in QUIC at all, even with just QUIC V1.
>
> A cellular network often knows something about mobile devices even
> when those devices are not actively using it. A device registers with
> a cellular network and gets an IP address. After that the cellular
> network keeps track of the device location area (only an area, not the
> exact location) even when the device is inactive or connected to WiFi.
> This is done in case some data destinated to the device (IP) arrives
> in the cellular network (PGW/UPF). Then the device is paged in the
> area and the data is delivered after the device becomes active. You
> can of cause turn off cellular if you don't want this.
>
Yes an No. If you do not turn on "airplane mode" or something similar,
the cellular network does indeed track the location of the device -- it
needs to do that if the device is to receive calls. But the cellular
network does not normally receive a copy of the data sent over the Wi-Fi
network. The ATSSS architecture changes that: instead of sending the
data from the device directly to the destination server, the packets
would take a detour through the ATSSS proxy of the cellular network
operator. At a minimum, this enables the cellular network to log the
connection's metadata.

-- Christian Huitema

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 3 Jun 2020 08:31:28 +0200

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

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

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 3 Jun 2020 08:41:20 +0200

Christian,

> between the two networks.

This end-to-end approach would indeed be possible with a multipath QUIC 
design. Note that the ATSSS service includes rules that determine which 
applications benefit from the service. It does not imply that all 
applications will use it.

AFAIK, many existing QUIC deployments are not really end-to-end 
deployments. Often, clients interact with an edge server that 
caches/proxies on behalf of origin servers.
> learn of the device's activity when the devices actually uses their network.

There are different ways to consider the privacy discussion. As an 
employee, my company might require me to always use a VPN service to 
access the Internet. That's a common policy in many companies. The ATSSS 
service can be considered as a kind of "VPN" service that network 
operators provide to their customers. As an enduser, I have a 
contractual relationship with my network provider and this contract can 
include strong privacy protections. Using the ATSSS service of a 
provider that I trust and needs to obey to specific laws could be better 
from a privacy viewpoint.

Olivier

---

From: Lars Eggert <[email-masked]>
Date: Wed, 3 Jun 2020 09:48:45 +0300

Hi,

(hat off)

On 2020-6-3, at 9:41, Olivier Bonaventure <[email-masked]> wrote:
> As an enduser, I have a contractual relationship with my network provider and this contract can include strong privacy protections. Using the ATSSS service of a provider that I trust and needs to obey to specific laws could be better from a privacy viewpoint.

so that's certainly debatable.

Apart from the privacy aspect though, tunneling all traffic through an operator proxy that would otherwise not be in the path certainly can have performance and management aspects. It's probably going to add delay due to route stretch and possibly queueing, and can limit throughput due to processing overheads or overload.

Lars

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 23:40:00 -0700

On 6/2/2020 11:31 PM, Olivier Bonaventure wrote:
> from the underlying network to the upper layer so that new
> applications can make informed and possibly better choices. 

I really wonder whether that argument applies to QUIC in 2020. Existing
and unmodified applications use TCP today, not QUIC.

QUIC capable applications have path migration capabilities built-in from
the start, which covers most of the "reliability" use cases of
multipath, without insert yet another middle-box in the setup.

-- Christian Huitema

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 3 Jun 2020 09:26:02 +0200

Christian,

> and unmodified applications use TCP today, not QUIC.

One of the use cases for ATSSSv2 is to simply carry Ethernet frames over 
the cellular and non-cellular networks.

> multipath, without insert yet another middle-box in the setup.

Path migration is a nice feature of QUICv1. I'd be interested in seeing 
measurements that compare QUICv1 path migration during handovers with 
MPTCP's approach to handover allows to use both paths during the 
handover. Experience with MPTCP shows that MPTCP's approach works well. 
If some has data on path migration with QUICv1 applications that do 
handovers, I'd be interested in looking at them.

Olivier

---

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Jun 2020 10:41:28 -0700

Just to amplify this a bit:

On Tue, Jun 2, 2020 at 11:49 PM Lars Eggert <[email-masked]> wrote:

>
> Apart from the privacy aspect though, tunneling all traffic through an
> operator proxy that would otherwise not be in the path certainly can have
> performance and management aspects. It's probably going to add delay due to
> route stretch and possibly queueing, and can limit throughput due to
> processing overheads or overload.
>
>
We've been through a lot of this before with various flavors of IP-layer
mobility, and the Home Agent approaches definitely showed all the issues
Lars cites above. There have been attempts to manage that with hierarchies,
fast hand-over rather than tunneling, and even new architectures like LISP
and RINA.   I don't think we want to re-learn all of those lessons from
scratch.  At the very least, we want to start with the understanding that
if ATSSS goes with this design that other tunneling protocols running on
top of it will be very difficult to debug and very hard to keep within
usable latencies.  Another comment mentioned VPNs, which are common and may
become more so.  If you have a user that has to deal with interaction
between the triangle routing to an operator proxy and the triangle routing
to a VPN end point, it will not be quick.

Traffic steering without full knowledge can manage some local
optimization,  and I don't want to denigrate that.  But those local
optimums do not necessarily result in better performance even for single
flows when the endpoints are not clear to steering mechanism.  If that is
priority, sticking with endpoint-based approaches rather than network
steering may be both cheaper and better.

regards,

Ted Hardie