Subject: More context on ATSSS use case

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 23 Oct 2020 19:45:21 +0000

Hi all,

based on the discussion yesterday I would like to provide some more context for the ATSSS use case and some notes that probably also applies to other proxy based-use cases.

First of all, I would like to clearly note that it's the client (UE) that has to request ATSSS support (a Multi-Access (MA)-PDU session) when connecting to the mobile network and it's also the client that starts the QUIC connection to the proxy (hosted in the UPF). Further for each connection that the client starts to some target content server, it can again decide to use the ATSSS setup or not (by otherwise connecting to the server over a single PDU mobile-network-only session). That means the endpoint can locally decide if it wants to only use the mobile link for certain connections instead of any kind of ATSSS service. However, that decision will likely not only depend on the application characteristics but also on e.g. the data subscription, user preferences, or device status.

And that brings me to another point: The right scheduling for the use of multiple paths does not only depend on the application characteristics. It's also the network conditions of each link, which to some extend can be measured in the transport if traffic is sent on both/all links, as well as other factors such as user tariff, remaining data volume, or battery status. Yes, this doesn't make the problem easier but we also don't need to solve this problem in a general way. For each of the proxy-based use cases presented yesterday there is a specific network setup with specific characteristics and goals. And often the two links do have quite different but known characteristics which does make the decision easier.

For the hybrid access case, you have one DSL and one mobile link and multipath is used for bandwidth aggregation. This setup is usually deployed when the physical line that is serving the DSL doesn't provide sufficient bandwidth and in certain areas upgrading those links would be very costly. In this case the scheduling is clear: you always fill up the DSL first and only use the mobile link when the DSL capacity is exhausted; this can happen for e.g. high quality video streaming. In that case the mobile link usually has a higher latency and you might need to wait a few more seconds before your video starts but I guess that's better than watching the video in low quality.

For ATSSS you always have one mobile 3GPP link and one non-3GPP link, usually wifi. And as I said in the chat yesterday, for ATSSS this will probably get first deployed with managed wifi networks, such that are often available today already by mobile operators in certain countries. ATSSS also provides a small number of so called "steering modes" which impacts the scheduling used, as presented by Spencer yesterday. These modes are provided by the network to the client (on the UE) as well as the proxy (hosted in the UPF) and these both tunnel endpoints decide independently which scheduling to use. 
	
There are different scenarios for these different steering modes, however, it's rather a small set of options. When selecting these modes the network is able to take additional factors into account such as subscriber data, operator configuration, or also application server provided info, e.g. for cases where there is actually an SLA between the content provider and network operator in place.

By default the scheduling could always prefer one link and only switch over when the performance is not sufficient anymore, e.g. the selected network gets loaded. While you can measure the network characteristics, and ATSSS will also rely on measured characteristics when deciding which path to use, the operator of the mobile and wifi networks might actually have some additional knowledge about the current network load (number of connected user, total traffic volume). Further both the UE as well as the UPF in the mobile network might actually have a better view about what's happening on the local link than the far end where the content server sits, e.g. knowing that a user is moving out of coverage. As such the network could for example provide a priority for one path when signaling the steering mode and may also indicate certain threshold values that could be used to make a switching decision. However, for most flows it might be even simpler than that and probably some kind of default mode will be used, e.g. based on lowest delay assuming that delay increases when one link gets congested.

Another scenario is that a user might choose a cheaper tariff where as much as possible of the downlink traffic is off-loaded to wifi. This needs to be implemented based on the scheduling in the UPF sitting in the mobile network. Further, as the steering modes are provided on a per flow level, another example scenarios is that bandwidth aggregation is requested for certain traffic flow based on an existing SLA. 

Please note that in any of these setups there are multiple e2e connection that use the same QUIC tunnel and as just noted each flow can have a different steering mode assigned. This is why simultaneous use of both paths is especially important for proxy-based use cases.

All these scenarios benefit from knowledge about the local network conditions to optimize resource usage and therefore also the performance for the user.

Hope that helps,
Mirja

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Oct 2020 14:08:25 -0700

Hi Mirja,

Can you clarify what you mean by "optimize resource usage and
therefore also the performance for the user"?
1) What does it mean in networking terms (latency, throughput, etc.)?
2) What does it mean in end-user terms (video loads faster, etc.)?

Thanks,
David

On Fri, Oct 23, 2020 at 12:45 PM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> Hi all,
>
> based on the discussion yesterday I would like to provide some more
> context for the ATSSS use case and some notes that probably also applies to
> other proxy based-use cases.
>
> First of all, I would like to clearly note that it's the client (UE) that
> has to request ATSSS support (a Multi-Access (MA)-PDU session) when
> connecting to the mobile network and it's also the client that starts the
> QUIC connection to the proxy (hosted in the UPF). Further for each
> connection that the client starts to some target content server, it can
> again decide to use the ATSSS setup or not (by otherwise connecting to the
> server over a single PDU mobile-network-only session). That means the
> endpoint can locally decide if it wants to only use the mobile link for
> certain connections instead of any kind of ATSSS service. However, that
> decision will likely not only depend on the application characteristics but
> also on e.g. the data subscription, user preferences, or device status.
>
> And that brings me to another point: The right scheduling for the use of
> multiple paths does not only depend on the application characteristics.
> It's also the network conditions of each link, which to some extend can be
> measured in the transport if traffic is sent on both/all links, as well as
> other factors such as user tariff, remaining data volume, or battery
> status. Yes, this doesn't make the problem easier but we also don't need to
> solve this problem in a general way. For each of the proxy-based use cases
> presented yesterday there is a specific network setup with specific
> characteristics and goals. And often the two links do have quite different
> but known characteristics which does make the decision easier.
>
> For the hybrid access case, you have one DSL and one mobile link and
> multipath is used for bandwidth aggregation. This setup is usually deployed
> when the physical line that is serving the DSL doesn't provide sufficient
> bandwidth and in certain areas upgrading those links would be very costly.
> In this case the scheduling is clear: you always fill up the DSL first and
> only use the mobile link when the DSL capacity is exhausted; this can
> happen for e.g. high quality video streaming. In that case the mobile link
> usually has a higher latency and you might need to wait a few more seconds
> before your video starts but I guess that's better than watching the video
> in low quality.
>
> For ATSSS you always have one mobile 3GPP link and one non-3GPP link,
> usually wifi. And as I said in the chat yesterday, for ATSSS this will
> probably get first deployed with managed wifi networks, such that are often
> available today already by mobile operators in certain countries. ATSSS
> also provides a small number of so called "steering modes" which impacts
> the scheduling used, as presented by Spencer yesterday. These modes are
> provided by the network to the client (on the UE) as well as the proxy
> (hosted in the UPF) and these both tunnel endpoints decide independently
> which scheduling to use.
>
> There are different scenarios for these different steering modes, however,
> it's rather a small set of options. When selecting these modes the network
> is able to take additional factors into account such as subscriber data,
> operator configuration, or also application server provided info, e.g. for
> cases where there is actually an SLA between the content provider and
> network operator in place.
>
> By default the scheduling could always prefer one link and only switch
> over when the performance is not sufficient anymore, e.g. the selected
> network gets loaded. While you can measure the network characteristics, and
> ATSSS will also rely on measured characteristics when deciding which path
> to use, the operator of the mobile and wifi networks might actually have
> some additional knowledge about the current network load (number of
> connected user, total traffic volume). Further both the UE as well as the
> UPF in the mobile network might actually have a better view about what's
> happening on the local link than the far end where the content server sits,
> e.g. knowing that a user is moving out of coverage. As such the network
> could for example provide a priority for one path when signaling the
> steering mode and may also indicate certain threshold values that could be
> used to make a switching decision. However, for most flows it might be even
> simpler than that and probably some kind of default mode will be used, e.g.
> based on lowest delay assuming that delay increases when one link gets
> congested.
>
> Another scenario is that a user might choose a cheaper tariff where as
> much as possible of the downlink traffic is off-loaded to wifi. This needs
> to be implemented based on the scheduling in the UPF sitting in the mobile
> network. Further, as the steering modes are provided on a per flow level,
> another example scenarios is that bandwidth aggregation is requested for
> certain traffic flow based on an existing SLA.
>
> Please note that in any of these setups there are multiple e2e connection
> that use the same QUIC tunnel and as just noted each flow can have a
> different steering mode assigned. This is why simultaneous use of both
> paths is especially important for proxy-based use cases.
>
> All these scenarios benefit from knowledge about the local network
> conditions to optimize resource usage and therefore also the performance
> for the user.
>
> Hope that helps,
> Mirja
>
>
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sat, 24 Oct 2020 01:07:25 +0000

Hi David,

this depends on the actual use case. Using multipath in a masque-like proxy setup covers multiple scenarios; in the hybrid access scenario it’s throughput, in other cases it can be latency, or a cheaper data subscription. That’s what I tried to explain below.

However, the whole point of ATSSS, as well as other use cases, is to provide the (mobile) operator’s costumer/the user better performance that what you have right now when using only a single path by actually making use of currently unused resources. We can argue what’s the best way to achieve that but you probably need to go to 3GPP and have that this discussion there. I was mainly trying to explain what ATSSS is, what the motivation is, and what the requirements are.

Mirja

From: David Schinazi <[email-masked]>
Date: Friday, 23. October 2020 at 23:08
To: Mirja Kuehlewind <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: More context on ATSSS use case

Hi Mirja,

Thanks,
David

On Fri, Oct 23, 2020 at 12:45 PM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Hope that helps,
Mirja

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Oct 2020 18:12:07 -0700

Hi Mirja,

I understand how in some scenarios this could increase throughput.
However, can you clarify how this could improve latency?

I'm noticing a pattern where no one is able to explain how this will
improve the end-user experience though, so I'm going to assume
that this is beneficial for carriers and not end-users. Unfortunately
I don't have the time to go to 3GPP and do this research myself.

David

On Fri, Oct 23, 2020 at 6:07 PM Mirja Kuehlewind <
[email-masked]> wrote:

> Hi David,
>
>
>
> this depends on the actual use case. Using multipath in a masque-like
> proxy setup covers multiple scenarios; in the hybrid access scenario it’s
> throughput, in other cases it can be latency, or a cheaper data
> subscription. That’s what I tried to explain below.
>
>
>
> However, the whole point of ATSSS, as well as other use cases, is to
> provide the (mobile) operator’s costumer/the user better performance that
> what you have right now when using only a single path by actually making
> use of currently unused resources. We can argue what’s the best way to
> achieve that but you probably need to go to 3GPP and have that this
> discussion there. I was mainly trying to explain what ATSSS is, what the
> motivation is, and what the requirements are.
>
>
>
> Mirja
>
>
>
>
>
>
>
> *From: *David Schinazi <[email-masked]>
> *Date: *Friday, 23. October 2020 at 23:08
> *To: *Mirja Kuehlewind <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: More context on ATSSS use case
>
>
>
> Hi Mirja,
>
>
>

---

From: Florin Baboescu <[email-masked]>
Date: Fri, 23 Oct 2020 19:53:56 -0700

Hi David,

I see that you are repeating a statement with which I definitely can not
agree “I'm noticing a pattern where no one is able to explain how this will
improve the end-user experience though, so I'm going to assume that this is
beneficial for carriers and not end-users.” So I’ll try to give it a try.
First I thought it was not necessary as there were already some great
presentations by Christoph, Olivier and the guys from Alibaba which should
have provided you with a very good reasoning on benefits for the end user.
I am not going to go again through what they presented.

               We also had one slide in our presentation, which may have
been overlooked, detailing at least three elements through which a
multipath access solution may improve the overall Quality of Experience for
the end user:

1)      Increased capacity, 2) increased coverage and 3) increased
reliability.

Let’s assume for simplicity an user which would be charged for the amount
of data he/she would use over a cellular network using licensed spectrum
while for all the data exchanged over the WiFi. While the user is under a
good WiFi coverage all his traffic is going to be routed over the WiFi, no
data traffic is going over the cellular. However, when the user is in an
area of limited coverage or the level of interference reaches a certain
threshold the quality of the communication over the WiFi access degrades.
As a result the achievable throughput over the WiFi may get below a certain
threshold. At this moment the WiFi access may not be able to sustain the
throughput the user may require. The user may either switch over to the
cellular (paying a higher penalty) or use both accesses, WiFi and cellular.
When both accesses are used,  all the traffic below a maximum threshold
will go over the WiFi access, while all the leftover traffic will go over
the cellular access.

In total for this example there are the following cases:

-          User entirely under the WiFi coverage

-          User entirely under the cellular coverage (no WiFi coverage)

-          User under both WiFi and cellular coverage

This solution essentially increases the coverage area for the user
complementing the use WiFi with cellular in zones of poor coverage or no
coverage.  Without it the user would have been left without data access in
areas of no WiFi coverage, or with a high rate of error and limited
throughput access in the areas of poor WiFi coverage or high interference.
The solution increases the reliability, allowing the user to backup the
primary access(in this case WiFi) with a secondary access (cellular).

On a side note I would also try to answer a different question. Is the
bandwidth aggregation solution always useful? Based on various companies
contributions in 3GPP it was noticed that there is no benefit for the user
to do bandwidth aggregation when the throughput ratio between the two
accesses exceeds somewhere between (3-5):1.

Another interesting use case addresses one of the limitations of WiFi (
before WiFi6, which uses an OFDMA based access). As many of you know, in
WiFi an user can transmit only after it detects that there is no one else
transmitting at the same time. Because of this when the number of users
served by the same access point increases the quality of the access
decreases, as all the users compete for the same access. In this case the
end user may use the WiFi access for all the downlink traffic while for the
uplink traffic may use the cellular access. This use case improves for the
end user both the capacity for both downlink and uplink as well as the
reliability.

These are just few examples which try to show the benefits of bringing a
multipath solution in the toolbox for both end user as well as network
elements/functions. I hope I brought some more clarity to you.

Regards,

-Florin

*From:* QUIC [mailto:[email-masked]] *On Behalf Of *David Schinazi
*Sent:* Friday, October 23, 2020 6:12 PM
*To:* Mirja Kuehlewind <[email-masked]>
*Cc:* [email-masked]
*Subject:* Re: More context on ATSSS use case

Hi Mirja,

David

Hi David,

this depends on the actual use case. Using multipath in a masque-like proxy
setup covers multiple scenarios; in the hybrid access scenario it’s
throughput, in other cases it can be latency, or a cheaper data
subscription. That’s what I tried to explain below.

Mirja

Hi Mirja,

Thanks,

David

Hi all,

based on the discussion yesterday I would like to provide some more context
for the ATSSS use case and some notes that probably also applies to other
proxy based-use cases.

By default the scheduling could always prefer one link and only switch over
when the performance is not sufficient anymore, e.g. the selected network
gets loaded. While you can measure the network characteristics, and ATSSS
will also rely on measured characteristics when deciding which path to use,
the operator of the mobile and wifi networks might actually have some
additional knowledge about the current network load (number of connected
user, total traffic volume). Further both the UE as well as the UPF in the
mobile network might actually have a better view about what's happening on
the local link than the far end where the content server sits, e.g. knowing
that a user is moving out of coverage. As such the network could for
example provide a priority for one path when signaling the steering mode
and may also indicate certain threshold values that could be used to make a
switching decision. However, for most flows it might be even simpler than
that and probably some kind of default mode will be used, e.g. based on
lowest delay assuming that delay increases when one link gets congested.

Another scenario is that a user might choose a cheaper tariff where as much
as possible of the downlink traffic is off-loaded to wifi. This needs to be
implemented based on the scheduling in the UPF sitting in the mobile
network. Further, as the steering modes are provided on a per flow level,
another example scenarios is that bandwidth aggregation is requested for
certain traffic flow based on an existing SLA.

Hope that helps,
Mirja

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Sun, 25 Oct 2020 18:05:24 +0000

Hello David and others,

ATSSS supports low latency applications in the following way (this is a quote from 23.700-93) as part of its “Priority-based” mode:

“RTT Threshold: Supported by using the RTT estimation mechanism defined in draft-ietf-quic-recovery, with which the QUIC protocol can estimate the RTT of a QUIC connection. Example of ATSSS rule using this steering mode: "Send the traffic of App1 to the access with RTT < 100ms; if both accesses have RTT < 100ms, send it to non-3GPP access". … As long as the selected access has RTT < 100ms, the traffic can remain on this access.”

I hope this clarifies that ATSSS is supporting what was called as Interactive service/Siri service in Christoph’s presentation.

And as explained by Mirja earlier it is the application that requests what kind of session it would like to have.

Best regards
Hannu

From: QUIC <[email-masked]> On Behalf Of Florin Baboescu
Sent: Saturday, October 24, 2020 5:54 AM
To: David Schinazi <[email-masked]>; Mirja Kuehlewind <[email-masked]>
Cc: [email-masked]
Subject: RE: More context on ATSSS use case

Hi David,

I see that you are repeating a statement with which I definitely can not agree “I'm noticing a pattern where no one is able to explain how this will improve the end-user experience though, so I'm going to assume that this is beneficial for carriers and not end-users.” So I’ll try to give it a try. First I thought it was not necessary as there were already some great presentations by Christoph, Olivier and the guys from Alibaba which should have provided you with a very good reasoning on benefits for the end user. I am not going to go again through what they presented.

               We also had one slide in our presentation, which may have been overlooked, detailing at least three elements through which a multipath access solution may improve the overall Quality of Experience for the end user:

  1.  Increased capacity, 2) increased coverage and 3) increased reliability.

Let’s assume for simplicity an user which would be charged for the amount of data he/she would use over a cellular network using licensed spectrum while for all the data exchanged over the WiFi. While the user is under a good WiFi coverage all his traffic is going to be routed over the WiFi, no data traffic is going over the cellular. However, when the user is in an area of limited coverage or the level of interference reaches a certain threshold the quality of the communication over the WiFi access degrades. As a result the achievable throughput over the WiFi may get below a certain threshold. At this moment the WiFi access may not be able to sustain the throughput the user may require. The user may either switch over to the cellular (paying a higher penalty) or use both accesses, WiFi and cellular. When both accesses are used,  all the traffic below a maximum threshold will go over the WiFi access, while all the leftover traffic will go over the cellular access.
In total for this example there are the following cases:

User entirely under the WiFi coverage

User entirely under the cellular coverage (no WiFi coverage)

User under both WiFi and cellular coverage

This solution essentially increases the coverage area for the user complementing the use WiFi with cellular in zones of poor coverage or no coverage.  Without it the user would have been left without data access in areas of no WiFi coverage, or with a high rate of error and limited throughput access in the areas of poor WiFi coverage or high interference. The solution increases the reliability, allowing the user to backup the primary access(in this case WiFi) with a secondary access (cellular).

On a side note I would also try to answer a different question. Is the bandwidth aggregation solution always useful? Based on various companies contributions in 3GPP it was noticed that there is no benefit for the user to do bandwidth aggregation when the throughput ratio between the two accesses exceeds somewhere between (3-5):1.

Another interesting use case addresses one of the limitations of WiFi ( before WiFi6, which uses an OFDMA based access). As many of you know, in WiFi an user can transmit only after it detects that there is no one else transmitting at the same time. Because of this when the number of users served by the same access point increases the quality of the access decreases, as all the users compete for the same access. In this case the end user may use the WiFi access for all the downlink traffic while for the uplink traffic may use the cellular access. This use case improves for the end user both the capacity for both downlink and uplink as well as the reliability.

These are just few examples which try to show the benefits of bringing a multipath solution in the toolbox for both end user as well as network elements/functions. I hope I brought some more clarity to you.
Regards,
-Florin

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David Schinazi
Sent: Friday, October 23, 2020 6:12 PM
To: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: More context on ATSSS use case

Hi Mirja,

David

On Fri, Oct 23, 2020 at 6:07 PM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

Mirja

From: David Schinazi <[email-masked]<mailto:[email-masked]>>
Date: Friday, 23. October 2020 at 23:08
To: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: More context on ATSSS use case

Hi Mirja,

Thanks,
David

Hope that helps,
Mirja

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 25 Oct 2020 18:18:31 +0000

Hey Hannu,

On Sun, 25 Oct 2020, 18:05 Flinck, Hannu (Nokia - FI/Espoo), <
[email-masked]> wrote:

> Hello David and others,
>
>
>
> ATSSS supports low latency applications in the following way (this is a
> quote from 23.700-93) as part of its “Priority-based” mode:
>
>
>
> “RTT Threshold: Supported by using the RTT estimation mechanism defined in
> draft-ietf-quic-recovery, with which the QUIC protocol can estimate the RTT
> of a QUIC connection. Example of ATSSS rule using this steering mode: "Send
> the traffic of App1 to the access with RTT < 100ms; if both accesses have
> RTT < 100ms, send it to non-3GPP access". … As long as the selected access
> has RTT < 100ms, the traffic can remain on this access.”
>
>
>
> I hope this clarifies that ATSSS is supporting what was called as
> Interactive service/Siri service in Christoph’s presentation.
>
>
>
So part of the benefit of QUIC is that connections can be reused for
different purposes. Using streams I can handle both an application that
requires low-latency (such as an API) along with bulk data transfer (such
as a software download) that has no hard requirement for completion time.

Iiuc ATSSS correctly, all it can do is forward QUIC packets. So how can it
pick the correct path the cases where a connection is mixed use?

Cheers
Lucas

---

From: David Schinazi <[email-masked]>
Date: Sun, 25 Oct 2020 12:17:42 -0700

Hi Florin,

Thank you for your response, please see comments inline.

David

On Fri, Oct 23, 2020 at 7:54 PM Florin Baboescu <
[email-masked]> wrote:

> agree “I'm noticing a pattern where no one is able to explain how this
> will improve the end-user experience though, so I'm going to assume that
> this is beneficial for carriers and not end-users.” So I’ll try to give
> it a try. First I thought it was not necessary as there were already some
> great presentations by Christoph, Olivier and the guys from Alibaba which
> should have provided you with a very good reasoning on benefits for the end
> user. I am not going to go again through what they presented.
>

The Apple and Alibaba presentations were great - but they were about
end-to-end multipath, not about ATSSS. My statement about user experience
is very specific to ATSSS.

> will go over the WiFi access, while all the leftover traffic will go over

Thank you - this is exactly the kind of user benefit I was asking for. In
other words: the user can save on monetary costs when watching a high
quality video in this very precise scenario of functional but slow Wi-Fi
while in range of high speed but expensive cellular. We can debate how
common this scenario is and how impactful the solution would be, but I
agree that this is an actual end-user benefit.

> primary access(in this case WiFi) with a secondary access (cellular).

I don't understand how this increases coverage, can you elaborate? Coverage
is determined by the cellular antennas and Wi-Fi access points available to
me. I can use all of them with QUIC connection migration end-to-end today,
or even plain-old TCP that creates a new connection on IP change - ATSSS
doesn't change the network coverage I have.

Similarly, I agree that in some circumstances this can increase overall
throughput, but I don't understand how it improves reliability, if anything
I think it'll reduce reliability by adding a new single point of failure in
the network - the ATSSS proxy.

> accesses exceeds somewhere between (3-5):1.

That's a useful datapoint, thanks! So it is restricting the use benefit
scenario above to only when Wi-Fi and cellular have comparable throughput.

> end user both the capacity for both downlink and uplink as well as the

I wouldn't call carrier sense a limitation of Wi-Fi, it's a very reasonable
design choice that's worked incredibly well for us so far. Sending the
uplink and downlink packets on different paths sounds like an interesting
research topic, has this been tried in practice?

---

From: David Schinazi <[email-masked]>
Date: Sun, 25 Oct 2020 12:20:33 -0700

Hi Hannu, response inline.

> Interactive service/Siri service in Christoph’s presentation.

There is a very big difference between "ATSSS supports low latency
applications" and "ATSSS improves latency". From the quote you posted, it
sounds like ATSSS is working hard to make sure it doesn't make latency too
much worse, but I'm not seeing anything indicating that it could make
latency better.

David

> *From:* QUIC <[email-masked]> *On Behalf Of *Florin Baboescu
> *Sent:* Saturday, October 24, 2020 5:54 AM
> *To:* David Schinazi <[email-masked]>; Mirja Kuehlewind <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: More context on ATSSS use case
>
>
>
> Hi David,
>
>
>

---

From: Florin Baboescu <[email-masked]>
Date: Sun, 25 Oct 2020 13:01:42 -0700

Hi David,

Please see inline [FFF]. Thanks.

-Florin

*From:* David Schinazi [mailto:[email-masked]]
*Sent:* Sunday, October 25, 2020 12:18 PM
*To:* Florin Baboescu <[email-masked]>
*Cc:* QUIC <[email-masked]>
*Subject:* Re: More context on ATSSS use case

Hi Florin,

David

Hi David,

[FFF] In the example I provided the primary access was over the WiFi
access. The coverage is increased by augmenting the coverage over the WiFi
with coverage over the cellular. While I do agree with you that QUIC
connection migration may be used in certain scenarios when you completely
switch from one access to another there are still plenty of space left in
which both accesses may be useful to being used. This scenario is not
covered by the connection migration. One example in which something like
this may happen is in areas of high interference or reduce signal strength
on the primary access, while the secondary access may still be throughput
limited.

[FFF] I’m not sure what do you mean by arguing that we insert a single
point of failure in the network – the ATSSS proxy. Trying to clarify this
point let me say, in a very simplistic way that the end to end path between
the terminal(UE) and a server(S) is made up of the following:

UE <-> access (cellular/WiFi) <-> UPF <-> S

The 3GPP ATSSS solution is based on the notion of a Multi Access PDN. In
this solution the ATSSS proxy is an on path functionality situated at the
UPF (aka user plane gateway function) with the goal that together with the
ATSSS functionality on the UE it accommodates one or more accesses being
used between the UE and UPF. So from this perspective I do not see how you
can state that we introduces a single point of failure in the network. On
the contrary the increased reliability is provided by augmenting one access
(in my example over WiFi) with a cellular access.

Let me try to provide you with another example. Let’s assume a client IMS
based application. The user uses WiFi as a primary access and would like to
start a high throughput session with a server. On the WiFi side the WLAN
modem may provide the application with “minimum throughput per access
class” that can be achieved at a specific moment. Based on this information
, the application uses IMS to negotiate the end to end pipe to the server
with a “guaranteed” throughput. While the quality of the access over WiFi
remains unchanged and the WiFi load is unchanged the “guaranteed” rate can
be sustained. However, when access characteristics change the value for
this metric may not be sustainable. In this case augmenting the WiFi access
with the cellular use addresses this lack of reliability.

 [FFF] Correct. When we discuss order of magnitude difference using
bandwidth aggregation does not make any sense. IT is like using a straw
when your toilet is overrun.

[FFF] Yes.

Regards,

-Florin

Hi Mirja,

David

Hi David,

Mirja

Hi Mirja,

Thanks,

David

Hi all,

Hope that helps,
Mirja

---

From: David Schinazi <[email-masked]>
Date: Sun, 25 Oct 2020 14:03:24 -0700

Hi Florin, comments inline after [DS].

David

On Sun, Oct 25, 2020 at 1:01 PM Florin Baboescu <
[email-masked]> wrote:

> I don't understand how this increases coverage, can you elaborate?
> Coverage is determined by the cellular antennas and Wi-Fi access points
> available to me. I can use all of them with QUIC connection migration
> end-to-end today, or even plain-old TCP that creates a new connection on IP
> change - ATSSS doesn't change the network coverage I have.
>
>
>

[DS] Your point here is that there might be value in using two paths. It
doesn't contradict my point that this does not increase coverage. My
definition of coverage is "the geographic area that is covered by networks".

> with the cellular use addresses this lack of reliability.

[DS] Let me clarify why ATSSS introduces a new point of failure. First
here's the common network topology today without ATSSS. In this example the
Client is a smartphone, and the user is browsing a website hosted by
WebServer.

[Client] ----- { cellular } ------- [WebServer]
    \------------{ Wi-Fi   } ------------/

The client has (at least) two IP addresses: IP_Client_cell and
IP_Client_WiFi.
The WebServer has IP_Server.

Now let's assume the Client is happily browsing using QUICv1 over one
interface, if that network goes down, QUIC will automatically migrate to
the other network and the web browsing will not fail. The client can send
packets to IP_Server on any interface and as long as one interface works
they will reach the server.

Now let's introduce ATSSS:

[Client] ----- { cellular } ------- [ATSSS Proxy] -------- [WebServer]
    \------------{ Wi-Fi   } ------------/

The ATSSS Proxy has IP_ATSSS.
The packets sent by the client are not sent to IP_Server here, they're sent
to IP_ATSSS.
If the ATSSS proxy becomes unreachable mid connection, the client's
connection will break - because it's sending to IP_ATSSS not IP_Server.

My point is that in this scenario ATSSS reduces reliability by adding a
point of failure.

> I wouldn't call carrier sense a limitation of Wi-Fi, it's a very
> reasonable design choice that's worked incredibly well for us so far.
> Sending the uplink and downlink packets on different paths sounds like an
> interesting research topic, has this been tried in practice?
>
> [FFF] Yes.
>

[DS] Great! I'd love to learn more. Do you know if the data is publicly
accessible?

---

From: Florin Baboescu <[email-masked]>
Date: Sun, 25 Oct 2020 16:19:58 -0700

Hi David. Inline [FFF2].

-Florin

*Sent:* Sunday, October 25, 2020 2:03 PM

David

Hi David,

-Florin

Hi Florin,

David

Hi David,

[FFF2] In my opinion the notion of coverage is user dependent and it does
have both a geographical and a temporal dimension. A user may find himself
out of the coverage for a service even without movement for various
reasons. From this point of view I have to admit that I do not quite
understand your definition of coverage.

The point I was trying to make that the area of coverage for a service for
a user may be increased by complementing the primary access of the user (in
my previous example WiFi access) with a secondary access. While I may have
an excellent coverage in my house using WiFi and I can access any video
services , as soon as I step outside of my house the quality of my WiFi
signal degrades rapidly with the distance from the WiFi AP. The application
becomes rate limited and as a result one can safely say that there is no
coverage for me for the video service I described at my desired rate.
However, if I would be able to complement my weak WiFi access outside the
house with a cellular access, then I may be in the position to be able to
run my application at the desired rate. In this context I can say that the
service coverage can be provided outside of the house. Similar argument can
be brought in the context of the temporal dimension for the coverage.

[FFF2] It looks like there is a misunderstanding on the ATSSS solution
here. As I mentioned before the basic element of the ATSSS solution is the
MA PDN session.  In a MA PDN session there is a single global IP
address/prefix associated with the client. All the packets sent by the
client are sent using the client global IP address as a source and the
destination IP of the server. The ATSSS function resides both at the client
and at the associated UPF. All the packets of the PDN session go through
the same associated UPF (which contains the ATSSS functionality). The ATSSS
function at the UE is provided with two local link IP Addresses which are
used to establish the MPQUIC connectivity to the ATSSS function at the UPF.

So in short the ATSSS MPQUIC based solution tunnels IP or Ethernet
packets/frames  between the ATSSS client application on the UE and the
ATSSS application on the UPF. The transport between the UE and UPF is
provided via QUIC encapsulation.

I’ll use the following notation:

IPg = global routable IP address at the UE

IPs = global routable IP address of the Web server

IP1 = local link IP address

IP2 = local link IP address

IP3 = local link IP address

IP4 = local link IP address

*Single Access PDN*

[Client] IPg----- { cellular } ------- [UPF] ------- IPs[WebServer]

*Multiple Access PDN with MPQUIC ATSSS*

[Client]  IPg  [ATSSS Client] IP1----- { cellular } ------- IP3 [ATSSS
Proxy][UPF] --------IPs [WebServer]

                                      IP2 \------------{ Wi-Fi   }
-------------------/IP4

Please note that one may think that there may be another deployment
scenario. *This scenario is NOT covered by the 3GPP ATSSS solution.* For
this scenario I do agree with you that it may introduce a potential point
of failure as the ATSSS node may not be on path. In this scenario the user
creates a single access PDN for Internet and uses the WiFi as a local
offload. For simplicity of the conversation I’ll limit the case to the the
terminal having a global routable address over WiFi (IPg2)and a global
routable address over cellular(IPg1). The ATSSS proxy may also need to
provide the client with a globally routable IP address reachable from the
client via the WiFi access. I not this address IPg3.

[Client]  IPg1  [ATSSS Client] IP1----- { cellular } -------[UPF] -------
IP3 [ATSSS Proxy][UPF] --------IPs [WebServer]

                                      IPg2 \------------{ Wi-Fi   }
---------------------------------------/IPg3

[FFF] Yes.

[FFF2] We can take this one offline as I do not think that it belongs in
this thread.

Regards,

-Florin

Hi Mirja,

David

Hi David,

Mirja

Hi Mirja,

Thanks,

David

Hi all,

Hope that helps,
Mirja

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Oct 2020 06:50:48 +0000

Hello Lucas

When a PDU session is established (PDU session is like setting up L2) a set of attributes will be exchanged between the UE and the 5G network. Part of the is the type of PDU session, such as multiaccess-PDU with steering mode information (e.g. load balancing, active-standby, etc. see the presentation for more details). The MP-QUIC connection is established per IP flow (5 tuple). With this information the UE will steer the traffic to the corresponding multipath-quic connection.

Best regards
Hannu

From: Lucas Pardue <[email-masked]>
Sent: Sunday, October 25, 2020 8:19 PM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>
Cc: Florin Baboescu <florin.baboescu=[email-masked]>; David Schinazi <[email-masked]>; Mirja Kuehlewind <[email-masked]>; [email-masked]
Subject: Re: More context on ATSSS use case

Hey Hannu,
On Sun, 25 Oct 2020, 18:05 Flinck, Hannu (Nokia - FI/Espoo), <[email-masked]<mailto:[email-masked]>> wrote:
Hello David and others,

And as explained by Mirja earlier it is the application that requests what kind of session it would like to have.
So part of the benefit of QUIC is that connections can be reused for different purposes. Using streams I can handle both an application that requires low-latency (such as an API) along with bulk data transfer (such as a software download) that has no hard requirement for completion time.

Iiuc ATSSS correctly, all it can do is forward QUIC packets. So how can it pick the correct path the cases where a connection is mixed use?

Cheers
Lucas

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Oct 2020 07:14:28 +0000

Hello David

I do not know where  this “ATSSS improves latency” comes from.

I can only find you own sentence “I'm noticing a pattern where no one is able to explain how this will improve the end-user experience though, so I'm going to assume that this is beneficial for carriers and not end-users” that talks about improving. But as you notice your original statement is not about improving latency but end-user experience.

Would you agree that end user experience get better (improves) if the performance is not fluctuating but steady to the limits that the two radio access can support?

This same applies to the reliability, mean time between failure calculations. If you have two parallel accesses you are better off than having one.
This is also the motivation why there are back links in many critical deployments.

Best regards
Hannu

From: David Schinazi <[email-masked]>
Sent: Sunday, October 25, 2020 9:21 PM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>
Cc: [email-masked]
Subject: Re: More context on ATSSS use case

On Sun, Oct 25, 2020 at 11:05 AM Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:
Hello David and others,

There is a very big difference between "ATSSS supports low latency applications" and "ATSSS improves latency". From the quote you posted, it sounds like ATSSS is working hard to make sure it doesn't make latency too much worse, but I'm not seeing anything indicating that it could make latency better.

David

Best regards
Hannu

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Florin Baboescu
Sent: Saturday, October 24, 2020 5:54 AM
To: David Schinazi <[email-masked]<mailto:[email-masked]>>; Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: More context on ATSSS use case

Hi David,

Hi Mirja,

David

Mirja

Hi Mirja,

Thanks,
David

Hope that helps,
Mirja

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 26 Oct 2020 08:20:28 +0000

Hey,

On Mon, 26 Oct 2020, 06:50 Flinck, Hannu (Nokia - FI/Espoo), <
[email-masked]> wrote:

> Hello Lucas
>
>
>
> When a PDU session is established (PDU session is like setting up L2) a
> set of attributes will be exchanged between the UE and the 5G network. Part
> of the is the type of PDU session, such as multiaccess-PDU with steering
> mode information (e.g. load balancing, active-standby, etc. see the
> presentation for more details). The MP-QUIC connection is established per
> IP flow (5 tuple). With this information the UE will steer the traffic to
> the corresponding multipath-quic connection.
>

I don't follow, sorry.

If a single IP flow carrying QUIC is used for multiplexing both low-latency
and bulk data, how do you resolve this?

Cheers
Lucas

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 26 Oct 2020 09:29:34 +0100

David,

> 
>     1)Increased capacity, 2) increased coverage and 3) increased
>     reliability.
> 
>     Let’s assume for simplicity an user which would be charged for the
>     amount of data he/she would use over a cellular network using
>     licensed spectrum while for all the data exchanged over the WiFi.
>     While the user is under a good WiFi coverage all his traffic is
>     going to be routed over the WiFi, no data traffic is going over the
>     cellular. However, when the user is in an area of limited coverage
>     or the level of interference reaches a certain threshold the quality
>     of the communication over the WiFi access degrades. As a result the
>     achievable throughput over the WiFi may get below a certain
>     threshold. At this moment the WiFi access may not be able to sustain
>     the throughput the user may require. The user may either switch over
>     to the cellular (paying a higher penalty) or use both accesses, WiFi
>     and cellular. When both accesses are used,  all the traffic below a
>     maximum threshold will go over the WiFi access, while all the
>     leftover traffic will go over the cellular access.
> 
> 
> Thank you - this is exactly the kind of user benefit I was asking for. 
> In other words: the user can save on monetary costs when watching a high 

Today, most of the WiFi networks that the user can access are:
- home Wi-Fi where he/she has manually added a WPA/WEP key
- enterprise/school WiFi that rely on 802.1x or similar technologies

In addition to these two isolated WiFi networks, there ongoing 
deployments of roaming solutions that will allow the users to 
automatically access millions of WiFi access points.

Those who are part of the academic community know eduroam (see RFC7593) 
that basically enables any student to use with his/her credentials the 
WiFi network of any university network throughout the world.

Several network operators have deployed authentication techniques that 
enable their customers to be authenticated in any of the WiFi access 
points that they have deployed in homes and in various locations like 
shopping malls, train stations, ...

In parallel, there are efforts to enable users to roam from one of these 
managed WiFi network to another. The openroaming initiative ( 
https://wballiance.com/openroaming/ ) is one example of these solutions.

With WiFi roaming, each user will be able to potentially access millions 
of WiFi access points. These WiFi access points will provide very 
different an unpredictable performance compared to a fully managed 
cellular network. With ATSSS, users will be able to use the roaming WiFi 
networks when they work well and automatically offload/switch to 
cellular when their performance is not sufficient.

We've all experienced the situation of been connected to a WiFi network 
in a pub and then need to manually disable WiFi to force the utilisation 
of the cellular network between the pub's DSL link is currently 
overloaded. ATSSS would make this seamless for the enduser for all 
applications and will also allow to use the WiFi network for part of the 
traffic which will be beneficial for the user's bill.

I expect that this scenario will be very common

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 26 Oct 2020 09:38:05 +0100

David,

> here's the common network topology today without ATSSS. In this example 
> the Client is a smartphone, and the user is browsing a website hosted by 
> WebServer.
> 

My understanding of most of today's QUIC deployments is that the client 
is not connected to the webserver but to a CDN or edge node that serves 
as a proxy to the webserver.

Thus the setup is

[Client] ----- { cellular } ------- [Edge]   ---------[WebServer]
       \------------{ Wi-Fi   } -------/

> the other network and the web browsing will not fail. The client can 
> send packets to IP_Server on any interface and as long as one interface 
> works they will reach the server.
> 
> The packets sent by the client are not sent to IP_Server here, they're 
> sent to IP_ATSSS.

The client will detect the failure of the ATSSS proxy and will then be 
able to switch to non-ATSSS to directly reach the webserver/edge node.
Since the client uses the ATSSS for multiple applications, a failure of 
the ATSSS proxy will be quickly detected.

> My point is that in this scenario ATSSS reduces reliability by adding a 

I don't see a difference between the failure of an Edge node and an 
ATSSS proxy. Both can be deployed with enough redundancy to limit the 
impact of failures. The only difference is that ATSSS nodes will 
probably be deployed by network operators while Edge nodes are deployed 
by CDN providers.

Olivier

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Oct 2020 12:49:50 +0000

Hello Lucas

No, there are multiple QUIC connections (multipath!). Please see slide #5 in
https://github.com/quicwg/wg-materials/blob/master/interim-20-10/Multipath%20in%203GPP%20ATSSS.pdf

Bulk data and low-latency are kept separate. Each QoS flow has its own connection.

Best regards
Hannu

Sent: Monday, October 26, 2020 10:20 AM

Hey,
On Mon, 26 Oct 2020, 06:50 Flinck, Hannu (Nokia - FI/Espoo), <[email-masked]<mailto:[email-masked]>> wrote:
Hello Lucas

I don't follow, sorry.

If a single IP flow carrying QUIC is used for multiplexing both low-latency and bulk data, how do you resolve this?

Cheers
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 26 Oct 2020 13:00:50 +0000

> Bulk data and low-latency are kept separate. Each QoS flow has its own

I'm not talking about the ATSSS tunnel part. I'm saying, when a QUIC client
and server want to multiplex different kinds of traffic in the same
connection, the transport let them do that using streams and datagrams with
application-specific scheduling.

I don't see an answer for how ATSSS can distinguish the different traffic
in end-to-end QUIC. So I don't see how it can select the different paths
that it knows about but the endpoints don't.

If the answer is something like "keep your different traffic on different
end-to-end connections." then that is a very sorry state of affairs and
undoes many benefits. So I'm hoping there is something I'm missing.

Cheers
Lucas

---

From: <[email-masked]>
Date: Mon, 26 Oct 2020 13:57:13 +0000

Hi Olivier, all, 

> ATSSS proxy. Both can be deployed with enough redundancy to limit
> the impact of failures. The only difference is that ATSSS nodes will
> probably be deployed by network operators while Edge nodes are
> deployed by CDN providers.

The main difference is that the ATSSS proxy will be ** explicitly signalled ** to the UE while the presence of any other on-path proxy is ** transparent ** to the UE.

The explicit mode in the ATSSS allows an UE to probe the path, react to path failures, decide to bypass the proxy, etc.

Cheers,
Med

> -----Message d'origine-----
> De : QUIC [mailto:[email-masked]] De la part de Olivier
> Bonaventure
> Envoyé : lundi 26 octobre 2020 09:38
> À : David Schinazi <[email-masked]>; Florin Baboescu
> <[email-masked]>
> Cc : QUIC <[email-masked]>
> Objet : Re: More context on ATSSS use case
> 
> David,
> 
> >
> >
> > here's the common network topology today without ATSSS. In this
> > example the Client is a smartphone, and the user is browsing a
> website
> > hosted by WebServer.
> >
> My understanding of most of today's QUIC deployments is that the
> client is not connected to the webserver but to a CDN or edge node
> that serves as a proxy to the webserver.
> 
> Thus the setup is
> 
> > interface, if that network goes down, QUIC will automatically
> migrate
> > to the other network and the web browsing will not fail. The
> client
> > can send packets to IP_Server on any interface and as long as one
> > interface works they will reach the server.
> >
> The client will detect the failure of the ATSSS proxy and will then
> be able to switch to non-ATSSS to directly reach the webserver/edge
> node.
> Since the client uses the ATSSS for multiple applications, a failure
> of the ATSSS proxy will be quickly detected.
> 
> > My point is that in this scenario ATSSS reduces reliability by
> adding
> > a point of failure.
> 
> ATSSS proxy. Both can be deployed with enough redundancy to limit
> the impact of failures. The only difference is that ATSSS nodes will
> probably be deployed by network operators while Edge nodes are
> deployed by CDN providers.
> 
> Olivier

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 26 Oct 2020 09:56:42 -0500

Hi all,

On Mon, Oct 26, 2020 at 2:14 AM Flinck, Hannu (Nokia - FI/Espoo) <
[email-masked]> wrote:

> I can only find you own sentence “I'm noticing a pattern where no one is
> able to explain how this will improve the end-user experience though, so
> I'm going to assume that this is beneficial for carriers and not end-users”
> that talks about improving. But as you notice your original statement is
> not about improving latency but end-user experience.
>
>
>
> Would you agree that end user experience get better (improves) if the
> performance is not fluctuating but steady to the limits that the two radio
> access can support?
>
>
>
> This same applies to the reliability, mean time between failure
> calculations. If you have two parallel accesses you are better off than
> having one.
>

Agree with Hannu.
I don't think multipath (or more correctly multi-interface) use decreases
latency. But I remind people that  the whole 5G is based on reducing
latency.
In 5G this is achieved by using more codes at the physical layer and by
using edge computing, i.e placing the UPF closer to the user.

Folks, we can not solve everything with quic :)

Behcet

> Best regards
>
> Hannu
>
>
>
> *From:* David Schinazi <[email-masked]>
> *Sent:* Sunday, October 25, 2020 9:21 PM
> *To:* Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>
> *Cc:* [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Mon, 26 Oct 2020 09:42:49 -0700

Hi Florin, inline [DS2].

> be brought in the context of the temporal dimension for the coverage.

[DS2] Thanks for clarifying. If I understand you correctly, your definition
of coverage is "the geographic area that is covered by networks that
provide throughput higher than X". With that definition, I agree with you
that this can improve coverage in the areas where there is coverage of
multiple networks where none of them individually meet the throughput
requirement but the sum does.

>                                       IP2 \------------{ Wi-Fi   }

[DS2] Thanks for the diagram. In this example, what IP addresses do the
packets for the end-to-end Client-WebServer connection use in both
directions? Because if they're encapsulated in the ATSSS client and
decapsulated in the UPF (and vice versa in the other direction), then if
the UPF becomes unreachable the connection breaks, right?

---

From: David Schinazi <[email-masked]>
Date: Mon, 26 Oct 2020 09:49:15 -0700

Hi Hannu,

> I do not know where  this “ATSSS improves latency” comes from.

I understood this email as Mirja claiming that ATSSS can improve latency:
https://mailarchive.ietf.org/arch/msg/quic/lcKeWUS04oJOtKbShbHUQ8PdT6s/

> performance is not fluctuating but steady to the limits that the two radio

In theory, absolutely! If we could magically use every network perfectly
then more networks is better. In practice we do not have perfect
information so the scheduler has to guess, and it can guess wrong.

> calculations. If you have two parallel accesses you are better off than

Again, that's true in theory but not immediate in practice. I'll also note
that you can improve reliability without multipath: a well tuned connection
migration stack will probe new interfaces as they appear and be ready for
hot standby on any reliability issue.

David

---

From: David Schinazi <[email-masked]>
Date: Mon, 26 Oct 2020 09:57:56 -0700

Hi Olivier, responses inline.

>        \------------{ Wi-Fi   } -------/

That's absolutely correct, but it's also orthogonal to this discussion. If
I'm
communicating with a WebServer, the fact that it's behind an L3 router
or an L4 load balancer or an L4 load balancer or edge is transparent.
Yes, all of those are point of failures, but that's orthogonal to whether or
not ATSSS introduces one more point of failure in addition to all existing
ones.

> the ATSSS proxy will be quickly detected.

How can it do this without the end-to-end QUIC connection failing?
Are you saying that the Client will migrate its end-to-end QUIC connection
away from the virtual ATSSS interface and go straight over Wi-Fi?

---

From: Florin Baboescu <[email-masked]>
Date: Mon, 26 Oct 2020 10:31:27 -0700

Hi David,

Please see inline [FFF3]. –Florin

*Sent:* Monday, October 26, 2020 9:43 AM

Hi Florin, inline [DS2].

Hi David. Inline [FFF2].

-Florin

David

Hi David,

-Florin

Hi Florin,

David

Hi David,

[FFF3] Yes, you can also look at it this way.

*Single Access PDN*

[FFF3] If I do understand correctly your question, between the Client and
the Web Server the IP packet has IPg and IPs for source and destination.
Your question “if the UPF becomes unreachable the connection breaks, right?
” is complementary to the overall ATSSS work.

I see the question be the same for the basic single access scenario:

You may also say that if UPF goes down the overall connection between the
Client and WebServer goes down. How the UPF management is handled in a 5G
network is detailed in 3GPP specifications and I do not want to go into
these details as I do not think it is useful in the context of this
conversation. However all that I want to mention here is that from a
reliability perspective placing the ATSSS anchoring point at the UPF does
not reduces the reliability comparing with the single access alternative
using the same UPF as an entry point. On the contrary the overall
reliability for the end to end path may be increased by the hybrid
link(which uses both accesses) that is created using ATSSS between the
Client and UPF.

[FFF] Yes.

Regards,

-Florin

Hi Mirja,

David

Hi David,

Mirja

Hi Mirja,

Thanks,

David

Hi all,

Hope that helps,
Mirja

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 26 Oct 2020 21:56:30 -0700

Hello,

> On Oct 25, 2020, at 12:18 PM, David Schinazi <[email-masked]> wrote:
> 
> 
> Hi Florin,
> 
>> On Fri, Oct 23, 2020 at 7:54 PM Florin Baboescu <[email-masked]> wrote:
>> Hi David,
>> 
>>  
>> 
> The Apple and Alibaba presentations were great - but they were about end-to-end multipath, not about ATSSS. My statement about user experience is very specific to ATSSS.

the benefits Apple’s users are getting out of an end-to-end use of multipath would be the same for an ATSSS based multipath.
It is unimportant where the transport layer session is terminated, as long as the diverse paths are between the two endpoints that are terminating the multipath session.

If ATSSS can provide multipath capabilities to end users even when servers are not multipath capable or do not have sufficient control or information to efficiently use the path diversity, then it is a win for the user’s experience.

Christoph 

>> 1)      Increased capacity, 2) increased coverage and 3) increased reliability.
>> 
>>  
>> 
> Thank you - this is exactly the kind of user benefit I was asking for. In other words: the user can save on monetary costs when watching a high quality video in this very precise scenario of functional but slow Wi-Fi while in range of high speed but expensive cellular. We can debate how common this scenario is and how impactful the solution would be, but I agree that this is an actual end-user benefit.
>  
> I don't understand how this increases coverage, can you elaborate? Coverage is determined by the cellular antennas and Wi-Fi access points available to me. I can use all of them with QUIC connection migration end-to-end today, or even plain-old TCP that creates a new connection on IP change - ATSSS doesn't change the network coverage I have.
> 
> Similarly, I agree that in some circumstances this can increase overall throughput, but I don't understand how it improves reliability, if anything I think it'll reduce reliability by adding a new single point of failure in the network - the ATSSS proxy.
>  
> That's a useful datapoint, thanks! So it is restricting the use benefit scenario above to only when Wi-Fi and cellular have comparable throughput.
>  
> I wouldn't call carrier sense a limitation of Wi-Fi, it's a very reasonable design choice that's worked incredibly well for us so far. Sending the uplink and downlink packets on different paths sounds like an interesting research topic, has this been tried in practice?
>  
>> From: QUIC [mailto:[email-masked]] On Behalf Of David Schinazi
>> On Fri, Oct 23, 2020 at 6:07 PM Mirja Kuehlewind <[email-masked]> wrote:
>> 
>> Hi David,
>> 
>>  
>> 
>> On Fri, Oct 23, 2020 at 12:45 PM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
>> 
>> Hi all,
>>

---

From: <[email-masked]>
Date: Tue, 27 Oct 2020 07:48:05 +0000

David,

The end-to-end QUIC connection will always survive.

If you refer to https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00#section-5.2, you will see that the external IP address seen by the remote server may be local to the ATSSS proxy or may be the one that is directly assigned to the UE.

Depending whether the UE’s address is preserved or not when the ATSSS proxy is involved, migrating flows outside the tunnel (for whatever reason) may or may not even require a connection migration!

Cheers,
Med

De : QUIC [mailto:[email-masked]] De la part de David Schinazi
Envoyé : lundi 26 octobre 2020 17:58
À : Olivier Bonaventure <[email-masked]>
Cc : QUIC <[email-masked]>
Objet : Re: More context on ATSSS use case