Internet Engineering Task Force G. Li Internet-Draft China Mobile Research Institute Intended status: Informational S. Randriamasy Expires: 13 January 2022 Nokia Bell Labs C. Xiong Tencent 12 July 2021 ALTO Uses Cases for Cellular Networks draft-li-alto-cellular-use-cases-00 Abstract This draft presents a number of use cases of applications running on endpoints located in cellular networks and whose performances highly depend on network information. This document first, shows how the performances of these applications can be further improved with ALTO provided abstracted network information and transportation means thereof. Second, upon reviewing the existing ALTO capabilities, it lists the ALTO features that need to be extended or defined to support the presented use cases. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Li, et al. Expires 13 January 2022 [Page 1] Internet-Draft ALTO Cellular Cases July 2021 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation And First Considerations . . . . . . . . . . . . . 5 2.1. Overview of challenges for applications on cellular networks . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Benefits expected from using ALTO to expose network topology to applications . . . . . . . . . . . . . . . . 6 2.3. First considerations on ALTO information features for wireless network . . . . . . . . . . . . . . . . . . . . 7 3. Example applications and use cases . . . . . . . . . . . . . 8 3.1. Use case 1: rate adaptation for cloud VR/gaming . . . . . 8 3.1.1. Application needs in information capabilities from network . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Missing ALTO information and features . . . . . . . . 10 3.2. Use case 2: Video-conferencing applications . . . . . . . 11 3.2.1. Application needs in information capabilities . . . . 12 3.2.2. How the application can get the 5G network information from ALTO . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Use case 3: ALTO supporting applications on UEs . . . . . 14 3.3.1. Use case: Access-aware AEP selection from UE with cascaded ALTO Servers . . . . . . . . . . . . . . . . 14 3.3.2. Scenario and assumptions . . . . . . . . . . . . . . 14 3.3.3. Missing ALTO information and features . . . . . . . . 15 4. Highlights on 3GPP Information Useful to ALTO . . . . . . . . 15 5. Gap analysis with Existing ALTO features . . . . . . . . . . 16 5.1. ALTO limits w.r.t. Cellular Network Information . . . . 16 5.2. ALTO Limits on network information transport: gap analysis with ALTO SSE . . . . . . . . . . . . . . . . . . . . . . 16 6. Summarizing ALTO added value and gaps for cellular networks . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Summarizing ALTO added value to cellular use cases . . . 17 6.2. Summarizing new ALTO features needed to support cellular use cases . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.1. ALTO Cellular Network Information . . . . . . . . . . 18 6.2.2. Efficient transport for ALTO Cellular Network Information based on SSE . . . . . . . . . . . . . . 18 6.2.3. Time constraints on ALTO-provided Cellular Network Information . . . . . . . . . . . . . . . . . . . . . 19 Li, et al. Expires 13 January 2022 [Page 2] Internet-Draft ALTO Cellular Cases July 2021 6.2.4. ALTO notifications to non-GBR as well as GBR traffic . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The ALTO protocol has been defined as modern network traffic started to convey a majority of user-initiated multimedia flows comprising essentially video payload. The purpose of ALTO is to alleviate network costs, congestion and load while maintaining application performances. To this end, ALTO provides to applications that have a choice among several endpoint location. This guidance consists for ALTO in exposing a Network Map that is a subjective abstraction of the Internet provider network. The Network Map is an arbitrary provider-defined partition of the provider topology in zones that have a human-readable identifier named PID and that gather network endpoints that may be treated similarly, see RFC7285 sec 5.1. Among these PIDs, the ALTO Cost Map defines abstracted network costs. The design of ALTO is flexible and generic enough to support further evolutions of application traffic and enable lightweight protocol extensions. In particular as per section 5.2 of RFC7285, "There are many types of addresses, such as IP addresses, MAC addresses, or overlay IDs.", while the 7285 "document specifies (in Section 10.4) how to specify IPv4/IPv6 addresses or prefixes." Likewise, the time granularity of ALTO path costs was intended in the initial requirements of RFC6708 to be in the order of days or more, extensions such as RFC 8688 specifies the value encoding in floating numbers, allowing thus smaller time interval durations. Nevertheless, ALTO is by no means meant to provide information in real-time. Li, et al. Expires 13 January 2022 [Page 3] Internet-Draft ALTO Cellular Cases July 2021 In the first two WG charters, the ALTO applications and use cases have focused on applications using network maps, cost maps defined on IP Networks. Nevertheless, while the central use case in the base protocol was peer-to-peer file sharing, the ALTO WG progressively moved to CDN use cases, following thus the usage trend and the needs of the service providers exposing their network abstraction. This has produced extensions supporting finer grained information in terms of network capabilities and time span. Applications are today evolving to require more resources, performance, service presence and reactivity. Modern Applications now span endpoints in both fixed and cellular networks. They are usually catered by Servers located at the edge or within the core network. Servers view and manage IP flows while Clients are associated to one or more flows defined according to their hosting network technology. For example, a Client located in 3GPP defined cell is mapped to a so-called QoS flow, that may map to one or more IP flows, either because the application involves say voice or video, or because the user equipment (UE) is running several applications simultaneously. These applications are also the most Quality of Experience (QoE ) demanding ones. The COVID period has witnessed frequent service degradation and interruption in applications such as videoconferencing or gaming on a mobile phone. The Servers need to be reactive enough to correctly adapt their resources to the challenged users. To do so, they need to have a reliable view of the network capabilities and bottlenecks, while that view should cover application paths end to end and not only at the user access network. There is a strong need for application vendors to sustain user QoE, especially low latency and acceptable throughput. Given the number of user flows, the complexity of the network and sensitivity of user and network information, the application server should get all and only what information it needs. In other words, the network abstraction exposed to applications must be reliable, preserve confidentiality, suit the application needs and minimize the data exchange volume. This draft emphasizes the importance of abstracted cellular information, as the cell resides in the last IP hop, which is usually the bottleneck. Therefore, last hop network information is critical. It is important to have end to end information for apps having cellular user footprint that covers both the edge and core Internet and the access plus the cloud. The current networking SDOs such as 3GPP, ETSI, IETF do not cover all these areas simultaneously but provide each a separate focused view. Note that it is the same for Open Source organizations such as Open RAN (ORAN) or Facebook sponsored - Open Computing Platform (OCP) providing in-band telemetry info for DC networks. Li, et al. Expires 13 January 2022 [Page 4] Internet-Draft ALTO Cellular Cases July 2021 This draft focuses on popular applications that have a user footprint in cellular networks. It explores on one hand the requirements of such applications in terms of network information, the capabilities of 3GPP network information functionalities such as the Network Exposure Function (NEF), and their the missing. On the other hand, it explores what ALTO may potentially provide to compensate and extend the scope of 3GPP information. The draft is thus motivated by the following "gaps" between ALTO and 3GPP: * Cellular information provided by 5G is limited in 2 ways: RAN scope only, and QoS negotiation for only given type of traffic (GBR), * ALTO on the other hand is generic regarding the type of access. However, it lacks small grain information and its dynamicity is currently limited. Above all, the ALTO protocol and its extensions are specified for IP networks. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Terminology TO BE COMPLETED QoS, ABR, RTT, GBR, XR/VR, AR, CGS 2. Motivation And First Considerations 2.1. Overview of challenges for applications on cellular networks This section lists some challenges faced by applications running on cellular networks that motivate the definition of ALTO-based network topology exposure to improve application performance. * New popular applications running on mobile networks: The current ALTO protocol exposes endpoint addresses or path information. ALTO was initially designed for P2P file or chunked data download applications. Nowadays, P2P-like applications are no more widely used. Instead, mobile internet got more popular, the price to buy legal music/video/ebook files for download or streaming from a dedicated service provider have dramatically reduced. Consequently, there is little need to allow a user to change the destination server address the path to destination server. The major challenge now is to better support applications running on Li, et al. Expires 13 January 2022 [Page 5] Internet-Draft ALTO Cellular Cases July 2021 the mobile internet. In 5G networking, selection of an destination application server and related path is no major issue: the 3GPP has defined a mechanism in [TS23.548] to let the application change the Edge Compute server on the fly during the download, where this change is automatic and transparent to the user. A bigger issue, in 5G networks, is how to adapt the application behavior, based on the data rate fluctuation in the mobile network. * 5G low-level network information too complex for application developers: Too detailed radio level (low layer) parameters are very hard to be understood by the application developers and are thus very hard to be tested for the application development and deployment. * Notifications of RAN changes restricted to GBR traffic: In 5G networks, notifications to CGS of QoS level change are currently sent only for Guaranteed Bit Rate (GBR) traffic whereas they should be used for non-GBR traffic as well. 2.2. Benefits expected from using ALTO to expose network topology to applications The first and fundamental benefit expected from ALTO is the ability to expose simple and abstracted network topology information to applications. An ALTO Client collocated with an application server could easily get concise and safe information allowing adaptive application behavior and QoE maintenance. Besides, with ALTO and its handy JSON contents, application developers can take advantage of the ALTO services to rapidly develop and update wireless applications with less changes in their code. Another important benefit is the ability of ALTO to support to exposition to applications of the QoS supported by a path, given that the supported QoS may vary over time. A fundamental ALTO service to support the 5G would be the notification of different bit rates supported in the access network. Providing such path QoS notification to is of highest importance, as it allows the applications to appropriately adapt their behavior, that is, in the present case, their bitrate. Given that the path QoS can vary very quickly, the information exchange must be fast, with simple terms, while moderating the volume of exchanged information. A first step in this direction is to introduce the definition of three levels of path QoS supported for applications, that can be defined in abstracted from 3GPP in ALTO terms. Each level may draw specific requirements on the interaction between ALTO Client and ALTO Server. Li, et al. Expires 13 January 2022 [Page 6] Internet-Draft ALTO Cellular Cases July 2021 * Basic Level: for e.g. video streaming; normal data rate, and loose latency requirements (e.g. network transport latency lower that 150ms)). In such case, the ALTO interaction can use the basic QoS Notification Control (QNC) and alternative QoS profile (different bit rate) defined in 5G. * Medium Level: for e.g. conference call; high data rate (e.g. higher than 5Mbps), but moderate vlatency requirement (e.g. network transport lower than 150 ms). In this case the ALTO interaction can use the QNC and small measurement time. * Hard/complex Level: for e.g. cloud gaming, XR/VR services; high data rate (e.g. higher than 5Mbps) and low latency (lower than 10ms for network transport, lower than 100ms end to end in service level) services. More technologies are being studied in 3GPP R18. e.g. new QoS Notification Type. It is desirable to have the same data model in ALTO to express the different QoS values or levels for different the use cases. 2.3. First considerations on ALTO information features for wireless network This draft does not aim at defining ALTO extensions to support applications on cellular networks. This section lists some initial considerations that would characterize such extensions. Firstly, the use cases and associated needs of this draft do not restrict to 5G cellular networks. They cover potential application queries for ALTO network information that happen within the first IP hop. Such needs may be true for 4G and 5G networks. Currently in ALTO, the only way for an application to get a more adequate QoS level is to use another path by selecting another endpoint. In a wireless network, the application must use the same path in which the QoS can change over time. The end user cannot create or select another path during an application session. But because of the physics of the wireless, the QoS of the wireless connection may change quickly, so the application in the end user and in the application server needs to detect the change of the QoS value and adapt the application bit rate accordingly. Therefore, if the ALTO service is used in a wireless network, we need to extend ALTO to support only one path but with changes in the path cost or supported QoS that occur very quickly, e.g. within seconds or sub-seconds. A first architectural assumption is needed here for the ALTO Server that would expose "below 1st hop" network information. We assume the availability of a Local ALTO Server, that manages the information Li, et al. Expires 13 January 2022 [Page 7] Internet-Draft ALTO Cellular Cases July 2021 covering the "below" first IP hop area delineated by the UEs and the Packet Data Network (PDN). In the use cases of this draft a Local ALTO Server may cover a 4G or 5G topology. It is queried by ALTO Clients that may be associated to application functions in the network edge or in end systems. It is not scalable to provide ALTO information on paths from all UEs to all application endpoints in the Internet. Therefore, it is desirable to use "cascaded" ALTO Servers, where a local server covers the relevant access area and can, if needed compose its information with a "core" ALTO Server that manages information at an IP hop level or above. Such a solution is proposed in sections 5.1 of [alto-cost-context] and section 2.3.3 of RFC 7971 on deployment cases. Thus: * A Local ALTO Server (LAOS): covers a local and restricted part of the network. It is typically located before the Internet gateway, in the access network. For example, it can be collocated with the NEF, as in the Cloud Gaming use case or with a gateway. It hosts the information on the local 4G/5G network, covering the paths between e.g. the UEs and the cells or the PGWs/UPFs. It may host an ALTO Client that sends an ALTO request to a "core" ALTO Server, covering the zone beyond the PGW/UPF. * A "core" ALTO Server covers the whole ISP network view, at the IP and beyond level, as it would if the "local ALTO Service" is not available or deactivated. That is, it does not see the details below the (UE, PGW/UPF) hop. 3. Example applications and use cases This section presents emblematic examples of application use cases on cellular networks. For each use case, it lists the network information needed to maintain or improve application performances, which one is available from 3GPP and from ALTO, which ones are missing. Current examples applications are: Cloud gaming, Conferencing, and use cases are divided in network-based decision making and UE-based decision making. 3.1. Use case 1: rate adaptation for cloud VR/gaming FOR FURTHER VERSIONS: Need artwork based on slide 1 of "ALTO Recharter for Wireless Use cases-V6SR-2004" 5G is beginning to be commercialized globally since 2020, and there is a great improvement regarding bandwidth enhancement and latency reduction. Cloud-based interactive streaming applications such as cloud Virtual Reality (VR) and cloud gaming are booming. Li, et al. Expires 13 January 2022 [Page 8] Internet-Draft ALTO Cellular Cases July 2021 This type of applications requires low latency and highly reliable transmission of motion tracking instructions from user to server in the cloud, while the cloud is required to perform the rendering of pictures per frame and deliver them to users with usually low latency and high data rate. The required end-to-end transmission delay may be as low as 20ms. The less the latency, the better the user QoE as, for instance, a slight extra delay may cause user dizziness. The downlink bandwidth normally depends on different parameter settings such as DoF (Degree of Freedom), image resolution, frame rate, adapted rendering and compression algorithm. For example, a high definition with 1080p with 60 frames per seconds may require at least 20Mbps and ultra-high definition with 4K may require more than 40Mbps. Cloud VR/gaming is regarded as one of killer applications as well as major traffic contributor to cellular 5G networks. The major advantages of cloud VR/gaming are easy and quick start since there is no need to download and install a big volume of software in the user device beforehand, and also it is cost effective and demands too moderate processing load in the user device. Last, it is also regarded as a more trusted solution. Thus, cloud gaming becomes a competitive replacement for console gaming using cheaper PCs or laptops. On one hand, the above cloud-based interactive applications normally require high bandwidth and low latency, on the other hand, a larger radio bandwidth implies larger variations since radio resources are shared and competed by mobile users in a cell. Therefore, the last mile radio link is viewed as the bottleneck of the QoE. To address this problem, the application usually estimates available bandwidth based on application-level measurements such as traffic throughput, RTT and latency. It then uses an adaptive bitrate (ABR) mechanism to change the video encoding bitrate so as to match the fluctuation of radio bandwidth. However, it is hard to accurately estimate or predict user cellular link status only from the application's perspective since only the cellular network has a full understanding of all users' radio channel status, traffic fluctuation, moving in and out of cells. Moreover, bandwidth estimation based on application level traffic throughput statistics, rather than radio channel capabilities may be inaccurate. 3.1.1. Application needs in information capabilities from network Based on the above use case analysis, it would be beneficial if the cellular network could inform the cloud streaming application on the cellular network link status. The following approaches may be considered. Li, et al. Expires 13 January 2022 [Page 9] Internet-Draft ALTO Cellular Cases July 2021 * The application uses request/response to query the link status from the cellular network for a specific user. This may cause extra latency since two way signaling is required. * The cellular network periodically reports network link status to the application. This may cause extra signaling overhead if the reporting period threshold is too frequent. * The application uses a pub/sub-like mechanism, specifically, the application may subscribe a certain condition (for example, whether the QoS requirement is satisfied or significant QoS change happens) for cellular network. As soon as the predefined condition is fulfilled, the notification will be triggered immediately and if the condition is not triggered, no signaling is involved. Obviously, this approach is more cost effective from signaling point of view and timely compared with request/response. The application may inform the cellular network of the following information ( not exhaustive list, new information may be added later): * QoS requirements of application, e.g., min and/or max bandwidth, latency * Significant QoS changes, e.g., 30% drop of bandwidth change The cellular network link status may include the following information (not exhaustive list, new information may be added later): * The available bandwidth and latency of the cellular network * Whether QoS requirements of application are satisfied or not by the radio network * Whether significant QoS changes happen 3.1.2. Missing ALTO information and features However, the current ALTO protocol and extensions are missing the following information. Li, et al. Expires 13 January 2022 [Page 10] Internet-Draft ALTO Cellular Cases July 2021 * The ALTO representation of the QoS of an application path requires to represent the path endpoints. That is the path source and destination. It the ALTO Endpoint Cost Service (ECS) is used, it requires to indicate the endpoints. This is possible for the destination, as it is the CGS, usually identified with an IP address. However, the UE address would to be identified with an identifier relating to cellular address. And the current ALTO protocol only supports IP addresses. * One possible workaround would be to identify a cell as a PID. However, a PID MUST specify the network addresses it contains and only IP addresses are supported. The path cost from a UE/Cell to a CGS should be specific to a cell, but the IP address that is provided to the UE is not. The ALTO Server should ensure that the metric used to indicate the quality of the path to a CGS reflects the specifics of a cellular network. 3.2. Use case 2: Video-conferencing applications In the current context of massive teleworking, reliable video- conferencing tools are of utmost importance. Poor experience or service interruption occur more than often and may be caused by factors impacting functions at both the Server end and the UE end. In 2019, over 500 million active users were using online personal live show services in China and there are 4 million simultaneous online audience watching a celebrity's show. Low delay live show requires the close interaction between application and network. Compared with conventional broadcast services, this service is interactive which means the audience can be involved and is able to provide feedback to the anchorwoman or the anchorman of the game. A gaming show has almost the same QoS requirements as videoconferencing. It broadcasts the game playing to all the audience, and also requires playing game interaction between the anchor and the audience. A delay lower than 100ms is desired. If the delay is too large, there will be undesirable degradation on user experiences especially in a large-scale show. To lower the latency and provide size-adjustable show content, the application also requires QoS information of the transport layer of the wireless. Li, et al. Expires 13 January 2022 [Page 11] Internet-Draft ALTO Cellular Cases July 2021 3.2.1. Application needs in information capabilities The bit rate of radio link changes quickly. If the bit rate is downgraded and the application still uses the previous bit rate to send in the downlink to the user, the RAN will soon be in congestion state, the user video will be frozen and user's QoE will be very bad. So, the application needs to detect the bit rates of the transport network. The DASH-based mechanism defined in MPEG can be used. However, while the DASH based mechanism is normally for the file download type video streaming, it is not suitable for the interactive video. In the interactive video case, the transport can provide the supported bit rate to the application, and application can adaptively change its video bit rate down to the supported network bit rate and there is no congestion anymore [TS 23.501]. The QoS Flow in the 5G cellular network is established to transport the video streaming for the conference, and application server may request the 5G network to provide network information by the steps as described below, and specified in [TS23.501]: * The application requests the 5G network to notify the link status and indicate whether the required GFBR (Guaranteed Flow Bit Rate) can no longer be guaranteed or can be guaranteed again. * The cellular network will notify the application that "GFBR can no longer be guaranteed" if the radio link cannot provide the required guaranteed bit rate. However, it does not specify the amount of guaranteed bit rate. In this case, the cloud video server (normally the medio server) will downgrade the video streaming bit rate in order to avoid the video service being frozen. However, since the video server does not know the currently supported bit rate, the downgraded bit rate may be still higher than the supported bit rate. After receiving the above notification, the video service may still be frozen frequently. If the video server downgrades the bit rate two much, the quality of the video may be too downgraded and the user QoE becomes unacceptable. * The cellular network will notify the application that "GFBR can no longer be guaranteed and the supported bit rate is XXX" if the radio link cannot provide the required guaranteed bit rate, but the cellular network can provide additional information of supported guaranteed bit rate. Upon receiving this notification, cloud video server can downgrade the video streaming bit rate below the indicated bit rate. In such case, the user QoE does not downgraded too much. Li, et al. Expires 13 January 2022 [Page 12] Internet-Draft ALTO Cellular Cases July 2021 * The cellular network will notify the application that "GFBR can be guaranteed again" if the radio link can provide the required guaranteed bit rate again (for example, the user handovers to another radio station). After receiving this notification, the cloud video server can upgrade the video streaming bit rate to the previous required guaranteed bit rate. In such case, the user QoE can be recover to the best. The application may inform the cellular network of the following, given that the list below will be completed in the future: * QoS requirements of application, e.g., the guaranteed bit rate, the alternative guaranteed bit rate. * The measurement time for the guaranteed bit rate, e.g. 2 seconds (i.e. 2000ms) or 200/500 ms (to improve the response time, i.e. more quickly to provide QoS Notification from the 5G RAN). The cellular network link status exposed to the application may include the following, given that the list below will be completed in the future: * "GFBR can no longer be guaranteed", * "GFBR can no longer be guaranteed and the supported bit rate is XXX", * "GFBR can be guaranteed again". All in all, the network should more quickly provide QoS Notification to the application 3.2.2. How the application can get the 5G network information from ALTO The application (i.e. the ALTO client) can use the restful API to subscribe and be notified by the message from the ALTO Server, the application can adaptively change its encoding scheme to make the bit rate just below the provided network bitrate notified by the network. Also, the application can be pushed to get the message from the ALTO server using the SSE as defined in RFC 8895[RFC 8895]. Li, et al. Expires 13 January 2022 [Page 13] Internet-Draft ALTO Cellular Cases July 2021 3.3. Use case 3: ALTO supporting applications on UEs This section presents use cases where a UE runs an application with the support of an ALTO Client. The application in the UE needs to decide to which application endpoint (AEP) in the Internet to connect. An AEP is assumed to be an application server for e.g. content download, videoconferencing, or other applications for which many servers are deployed. For now, the ALTO-based selection of an AEP is usually done in the network, sometimes with the help of an authoritative entity based on the cost or performance of the path from the UE to the AEP. However, the capabilities of the access network, in the first path IP hop, may highly impact the application performance and therefore needs a deeper insight. The use cases in this section illustrate how network abstraction within the first hop can be beneficial to optimize application path performance. 3.3.1. Use case: Access-aware AEP selection from UE with cascaded ALTO Servers In this use case, a UE is located in a 4G or 5G network and may connect via several access technologies, e.g. 4G/5G Cellular or WiFi. It is assumed that the UE has subscribed to the same ISP for both fixed and mobile access with a given Service Level Agreement SLA. Users and ISPs tend usually prefer fixed or WiFi connection to cellular, because it is cheaper, more performant and cellular resources are limited. However, it is observed that in many places, including some urban areas in countries with a good average network infrastructure, the fixed network coverage is very poor and worse than the cellular coverage, so that users need to connect via a cell phone or a 4G/5G dongle. Sometimes also, MNOs and ISPs have spare data resources or offer them for free or at low price to users, depending on their SLA. For both parties, access-aware Endpoint selection for users is thus beneficial. The major QoE challenges in wireless network arise in the access network, that is, in the first hop, between the UE and its one or more associated packet data network gateways (PGW for 4G) or user plane function (UPF for 5G). The path of a UE to its associated PGW/ UPF impacts the path to the AEP and thus the application QoE. Therefore, once the PGW/UPF has been selected and will stay unchanged, it is beneficial to help the UE selecting between Cellular and WiFi access. 3.3.2. Scenario and assumptions The end to end path from the UE to the AEP is considered in 2 parts * the path from the UE to the PDN, Li, et al. Expires 13 January 2022 [Page 14] Internet-Draft ALTO Cellular Cases July 2021 * the path from the PDN to the AEP. FOR FUTURE VERSIONS: ARTWORK ON SCENARIO We assume the availability of multiple cascaded ALTO Servers, as mentioned in section XXXX, to provide a (UE, AEP) path cost. In our "cascaded" use case, we define 2 types of servers involved in conveying the end to end ALTO (UE, AEP) path cost, as follows: * A Local ALTO Server (LAOS): hosts the information restricted to the local 4G/5G network, covering the paths between e.g. the UEs and the cells or the PGWs/UPFs. It receives the ALTO request issued by the local ALTO Client LAOC associated to the UE. It May host an ALTO Client that can send an ALTO request to a "core" ALTO Server, covering the zone beyond the PGW/UPF, if needed by the application. It composes, when applicable, the response of the "core" ALTO Server with its own response to the LAOC query to obtain a better-informed end to end view of the application path. * A "core" ALTO Server covers the whole ISP network view, as it would if the "local ALTO Service" is not available or deactivated. That is, it does not see the details below the (UE, PGW/UPF) hop. 3.3.3. Missing ALTO information and features However, the ALTO information in the path between a UE and an AEP currently provides a cost for one single path only. It does not consider that multiple paths to the PGW/UPF are possible. Currently, the access technology is accounted in RFC 7971 (on deployment cases) in the last hop, to prefer selecting an AEP located in a fixed network over an AEP located in a mobile network. One way to achieve this is that ALTO provides a path cost that, for a given metric, takes multiple values each depending on parameters such as access technology and the access technology or SLA. 4. Highlights on 3GPP Information Useful to ALTO This section lists the 3GPP information that can be used by ALTO. Either as it comes in, with a minimal encapsulation, or as input to an aggregated form. In 3GPP specifications [TS23.501, 23.502, 23.503], the following mechanisms have been specified to enable the interaction between AF (application function) and NEF (network exposure function) from network's perspective. * Alternative QoS profiles, Li, et al. Expires 13 January 2022 [Page 15] Internet-Draft ALTO Cellular Cases July 2021 * notification control. The application inform the cellular network of the specific QoS requirements, which may include a list of QRP( QoS requirement parameters, such as min/max bandwidth) in a prioritized order. Such requirements will be conveyed to the RAN and the RAN will always try to fulfil the QoS requirement in the list with highest priority. And in the meantime, whether QoS requirements is fulfilled or not in each item of the list will be notified to the application timely. In order to avoid too frequent signalling, it is assumed that RAN can apply hysteresis (e.g., via a configurable time interval) to reduce too much signalling overhead. On the other hand, the QoS values within the list of QoS requirements are required not to be too close to each other. 5. Gap analysis with Existing ALTO features This section assesses the currently existing ALTO features against the needs in network information and related transport capabilities listed along with the use cases. 5.1. ALTO limits w.r.t. Cellular Network Information ALTO is by design not expected to provide real time information. The initial use cases were defined for cost maps conveying BGP-based path costs. Later use cases for CDN and video download on individual end- systems support finer grained network information. Nothing though prevents ALTO information to be in minutes or sub-minutes frequency. ALTO may convey values that are valid for a couple of seconds. However, an interval of 2 seconds, in regard of a cellular, network may be too large. 5.2. ALTO Limits on network information transport: gap analysis with ALTO SSE In RFC8895, ALTO Incremental Updates Using Server-Sent Events (SSE) introduces a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: * (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes * (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. Li, et al. Expires 13 January 2022 [Page 16] Internet-Draft ALTO Cellular Cases July 2021 SSE is a well-shaped pub/sub-like mechanism based on subscription, which quite matches the requirements of proposed cellular use cased in section XXXX, for example, cost effective and immediate. Therefore, SSE can be used as a baseline for protocol extension of cellular use cases. The following message flows can be reused. In the following figure, init request of step 1 is used to subscribe QoS requirements. Data update message of step 2a is used to notify whether subscribed QoS requirements are satisfied or not. FUTURE VERSIONS: ARTWORK ON SSE COMES HERE Based on the existing SSE message flows, attributes should be extended for each message flow for the proposed cellular use cases. For example, subscribed QoS parameters and conditions in step 1, the corresponding notification/data update in step 2a. 6. Summarizing ALTO added value and gaps for cellular networks 6.1. Summarizing ALTO added value to cellular use cases * ALTO abstraction covers several network technologies * ALTO abstraction covers several network scopes (RAN, edge, core, transport, WAN) * ALTO can aggregate network information over several technologies and scopes ALTO can provide end to end path information with insight on selected parts. To our knowledge, standards covering the RAN, the edge, the transport and the WAN (cite 3gpp, ETSI, others) provide a separate network view to applications, if ever. There is therefore no way currently for applications to get an integrated view, allowing more informed decisions. Additionally, ALTO provides abstracted network information, that protects operator confidentiality by exposing only relevant information to applications. This last aspect adds simplicity to the efficiency gained with network-aware decisions. Simplicity all the more allows quick decisions, which is crucial in cellular networks, that have high dynamics. 6.2. Summarizing new ALTO features needed to support cellular use cases The uses cases presented in this draft are stressing the need for new or extended ALTO features to convey cellular network information. This section also lists a number of concerns raised, in some cases, by the exposure of particular cellular information to third party applications. Other needs may be identified as the cellular use cases will be further investigated. Li, et al. Expires 13 January 2022 [Page 17] Internet-Draft ALTO Cellular Cases July 2021 6.2.1. ALTO Cellular Network Information ALTO features to represent identify a cell or a WiFi access point. Abstracted and simplified metrics and costs for wireless networks: ALTO Clients can request a list of supported values for a given set of ALTO metrics. All these metrics are easy to be understood and to be tested by the application developer and application platform (service provider). Examples of useful metrics for our use cases include: throughput/bit rate, latency, priority, error rate, Jitter. Most of these metrics are being standardized in [alto-performance- metrics]. However, their values need to be abstracted from the data provided by the 5G network, typically via the NEF. Other associated parameters associated to path cost metrics may be useful. For instance, a new type of useful metric would be an abstracted form of the time span to measure the bit rate. The network also needs to expose the attributes of supported alternative QoS. These include alternative throughput/bit rate, the time span to measure the bit rate, latency, priority, error rate, Jitter and associated priority. Other abstracted and simplified parameters, thresholds or attributes If radio level or low layer information are provided, a gateway is needed to translate or map these information to the high level terminology the ALTO Server. ALTO can then provide the abstracted information to the application. This gateway can be implemented in the southbound of the ALTO server and the gateway can be NEF or NWDA, see reference to 3GPP TS XXx, TS23.288. 6.2.2. Efficient transport for ALTO Cellular Network Information based on SSE Improvements are necessary of the following ALTO SSE features: FUTURE VERSIONS: ARTWORK ON EXTENDED SSE COMES HERE Based on the existing SSE message flows, attributes should be extended for each message flow for the proposed cellular use cases. For step 1 in the procedure of "init request", the following parameters may be included: * User IP flow ID, or other information relating to UE IP address * DL/UL capabilities * A list of QoS requirements and conditions including: Priority, Min bandwidth, Max bandwidth, delay threshold Li, et al. Expires 13 January 2022 [Page 18] Internet-Draft ALTO Cellular Cases July 2021 For step 2a, the corresponding notification/data update can be included regarding subscribed QoS parameters and conditions in step 1. * User IP flow ID, or other information relating to UE IP address * DL/UL capabilities * A list of QoS requirements and conditions including: Priority, current bandwidth or current delay 6.2.3. Time constraints on ALTO-provided Cellular Network Information The main constraint when conveying ALTO information is speed. When a significant change occurs in the RAN it should be ideally be notified to an application in real-time. As this is not feasible with ALTO, it is necessary to specify constraints such as: acceptable notification delay, maximum delay beyond which the application performance would get degraded, parameters defining an acceptable degradation. A typical example is as follows. The default measurement time for the guaranteed bit rate is 2000ms, and the maximum rate of notification is 1 time every 2 seconds in the case of data rate fluctuation. This causes too much latency for low latency (lower than 10ms) and/or high date rate (higher than 20mbps) services such as cloud gaming. But it is acceptable for normal latency (e.g. higher than 150ms) and normal data rate (lower than 5mbps) services. The measurement time can be changed to 500ms or 200ms to improve the response time, but the total number of notifications should not increase too much. That is, the total number of notification times should be the same level with the measurement time = 2000ms in a long time span such as 1 hour. As opposed to fixed networks for which ALTO was initially specified, mobile networks, especially RAN have high traffic and network state dynamics. ALTO is by no means expected to provide real-time information. A careful design of 5G metrics abstraction and hysteresis thresholds triggering ALTO notifications is necessary. The resulting non-real time but highly dynamic ALTO information can reduce the volume of data exchanged with the applications and in some extent facilitate anticipation and reduce oscillations. Li, et al. Expires 13 January 2022 [Page 19] Internet-Draft ALTO Cellular Cases July 2021 6.2.4. ALTO notifications to non-GBR as well as GBR traffic In 5G networks, notifications to CGS are currently sent only for Guaranteed Bit Rate (GBR) traffic whereas they should be for non-GBR traffic as well. In practice nothing prevents an ALTO Server to do so. To this end, the ALTO Server needs to have the necessary identifiers of the IP flow that is impacted by the network conditions (or QoS level) change. 7. Acknowledgements 8. IANA Considerations This draft includes no request to IANA. 9. Security Considerations FUTURE VERSIONS: TBC 10. References 10.1. Normative References [min_ref] authSurName, authInitials., "Minimal Reference", 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [DOMINATION] Mad Dominators, Inc., "Ultimate Plan for Taking Over the World", 1984, . [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Li, et al. Expires 13 January 2022 [Page 20] Internet-Draft ALTO Cellular Cases July 2021 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . Appendix A. Additional Stuff This becomes an Appendix. Authors' Addresses Li Gang China Mobile Research Institute Beijing China Email: ligangyf@chinamobile.com Sabine Randriamasy Nokia Bell Labs Nozay France Email: sabine.randriamasy@nokia-bell-labs.com Chunshan Xiong Tencent Beijing China Email: chunshxiong@tencent.com Li, et al. Expires 13 January 2022 [Page 21]