Re: More context on ATSSS use case

David Schinazi <dschinazi.ietf@gmail.com> Sun, 25 October 2020 21:03 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFD3A160B for <quic@ietfa.amsl.com>; Sun, 25 Oct 2020 14:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYuBzl2B0z5w for <quic@ietfa.amsl.com>; Sun, 25 Oct 2020 14:03:37 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055363A1609 for <quic@ietf.org>; Sun, 25 Oct 2020 14:03:37 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id m16so7600775ljo.6 for <quic@ietf.org>; Sun, 25 Oct 2020 14:03:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H3Fpi1HWpXKd3E1REPPAzDu82saJwWoOdAZaQgr7Itw=; b=ttoniiXQBAceIsWSY+gZHLbN5dbPM+kNCFjQKN7jneHelFg4+oDKKMZzcl18k2fWHV mpok2YpvsknYu/dtz6jHxL1ZLpQDevB+gNHWQXPsUnwypXDL8Mhfqve+cqnGhZXMdWI8 aWtpr66wW0yDQYAzxPlZ8CH5w9qdLTdciVQpFx8pAg352s+hW3LDzvRS9lEYHUzlejg7 NAQbpy/Jng7at0AUIe38Eia77h3V6pRzFODE61m4BjFqmGeCJWlUdhRLSFDjKXxUo+jv bpE4dMD8kRUdZ6+01A9HKEEpFU7tsEpybredb0fORhx8PgDWLA1U/E/dPZlxlFlCY7ja PMLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H3Fpi1HWpXKd3E1REPPAzDu82saJwWoOdAZaQgr7Itw=; b=rDxYtT/SBctMTeSZd8fwCaXyk6Ubl55XI+jletyP7xIDvq0iWdcLZfV0hqA7nUwNJr M/nXZSEdoJ65hJbmLgFkB7t0a+pg2gebqFn54OVEZ4xbF+nBO/GUvkQCHWn97rwgl9UR nO5fnMF2WmkdzoN2p60w8QjzjJ8kHcDdopfycwNtT2ncQK8oHmPlPc9Uncc9gkwzIcTA vsBpsPHRjby5URT1Bfwr25a8mIdjKxFHQpcxDAng5AkYknhecH1lorzwb/k79d/J7TDU 8uG9bkK6HNofLwnajEICm+TfV1U4kK5sGxvkdIubWRixobPr9xmgxcPr87/MCe/HRAE5 N9Mw==
X-Gm-Message-State: AOAM532O7KMROMaG4X5nNBCTTaPvGaClqsqx53Kz5rtmKVYiw61/AUzf +YCdzAFl0u4d2IovXXTxtXyjtP/93z7nUBL5+Sw=
X-Google-Smtp-Source: ABdhPJzczKZdPR6NO6Qa6Hy57dYmJq9kZtLFTAn31tjxTrzgK0RhgOVd8yFbeSLVwGknkZZiVVlBdcbCvW/kYchf3Ug=
X-Received: by 2002:a2e:45d6:: with SMTP id s205mr4679254lja.333.1603659815179; Sun, 25 Oct 2020 14:03:35 -0700 (PDT)
MIME-Version: 1.0
References: <50316F2A-931B-483E-B2CC-023C91AE91F0@ericsson.com> <CAPDSy+6k13fW_oQuEhmyQsMY9PH2DrVvKQ-DnJ=kQk5tTsN7TA@mail.gmail.com> <77E53AF0-6435-492A-B20A-5C18372BD1F8@ericsson.com> <CAPDSy+5pc7bPDXUT0uNu2MtD-MgVD7fXpG22eYY+7pmVBi30pw@mail.gmail.com> <0d7b0483916b3876934ed195075d8d72@mail.gmail.com> <CAPDSy+5Rfy77=iNNeg--YinfKvhmSThDJ98sN6WNyNvhX-d9MQ@mail.gmail.com> <cdd11cd390de134c98c6aa51a2b9bca7@mail.gmail.com>
In-Reply-To: <cdd11cd390de134c98c6aa51a2b9bca7@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Sun, 25 Oct 2020 14:03:24 -0700
Message-ID: <CAPDSy+4uQ_TxcfFZpTDNqjj6js3VABpntOLyAz0HV+q7fpCkXg@mail.gmail.com>
Subject: Re: More context on ATSSS use case
To: Florin Baboescu <florin.baboescu@broadcom.com>
Cc: QUIC <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009fd72a05b2852557"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7whnujJ_Rw7mJD7VmOzkuEzDe2E>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Oct 2020 21:03:41 -0000

Hi Florin, comments inline after [DS].

David

On Sun, Oct 25, 2020 at 1:01 PM Florin Baboescu <
florin.baboescu@broadcom.com> wrote:

> Hi David,
>
> Please see inline [FFF]. Thanks.
>
> -Florin
>
>
>
>
>
> *From:* David Schinazi [mailto:dschinazi.ietf@gmail.com]
> *Sent:* Sunday, October 25, 2020 12:18 PM
> *To:* Florin Baboescu <florin.baboescu@broadcom.com>
> *Cc:* QUIC <quic@ietf.org>
> *Subject:* Re: More context on ATSSS use case
>
>
>
> Hi Florin,
>
>
>
> Thank you for your response, please see comments inline.
>
>
>
> David
>
>
>
> On Fri, Oct 23, 2020 at 7:54 PM Florin Baboescu <
> florin.baboescu@broadcom.com> wrote:
>
> 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.
>
>
>
> 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.
>
>
>
>                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.
>
>
>
> 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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> [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.
>

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

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

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

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


> 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:quic-bounces@ietf.org] *On Behalf Of *David Schinazi
> *Sent:* Friday, October 23, 2020 6:12 PM
> *To:* Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> *Cc:* quic@ietf.org
> *Subject:* Re: More context on ATSSS use case
>
>
>
> 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 <
> mirja.kuehlewind@ericsson.com> 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 <dschinazi.ietf@gmail.com>
> *Date: *Friday, 23. October 2020 at 23:08
> *To: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> *Cc: *"quic@ietf.org" <quic@ietf.org>
> *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=
> 40ericsson.com@dmarc.ietf.org> 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
>
>