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 protected]> 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 protected]> > *Date: *Friday, 23. October 2020 at 23:08 > *To: *Mirja Kuehlewind <[email protected]> > *Cc: *"[email protected]" <[email protected]> > *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= > [email protected]> 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 > >
