Re: More context on ATSSS use case

[David Schinazi <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]>
> *Date: *Friday, 23. October 2020 at 23:08
> *To: *Mirja Kuehlewind <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *Re: More context on ATSSS use case
>
>
>
> 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=
> [e-mail]> 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
>
>