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
