idnits 2.17.1 draft-li-alto-cellular-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 8895' is mentioned on line 593, but not defined == Unused Reference: 'DOMINATION' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 922, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Li 3 Internet-Draft China Mobile Research Institute 4 Intended status: Informational S. Randriamasy 5 Expires: 13 January 2022 Nokia Bell Labs 6 C. Xiong 7 Tencent 8 12 July 2021 10 ALTO Uses Cases for Cellular Networks 11 draft-li-alto-cellular-use-cases-00 13 Abstract 15 This draft presents a number of use cases of applications running on 16 endpoints located in cellular networks and whose performances highly 17 depend on network information. This document first, shows how the 18 performances of these applications can be further improved with ALTO 19 provided abstracted network information and transportation means 20 thereof. Second, upon reviewing the existing ALTO capabilities, it 21 lists the ALTO features that need to be extended or defined to 22 support the presented use cases. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 13 January 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Motivation And First Considerations . . . . . . . . . . . . . 5 61 2.1. Overview of challenges for applications on cellular 62 networks . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Benefits expected from using ALTO to expose network 64 topology to applications . . . . . . . . . . . . . . . . 6 65 2.3. First considerations on ALTO information features for 66 wireless network . . . . . . . . . . . . . . . . . . . . 7 67 3. Example applications and use cases . . . . . . . . . . . . . 8 68 3.1. Use case 1: rate adaptation for cloud VR/gaming . . . . . 8 69 3.1.1. Application needs in information capabilities from 70 network . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.2. Missing ALTO information and features . . . . . . . . 10 72 3.2. Use case 2: Video-conferencing applications . . . . . . . 11 73 3.2.1. Application needs in information capabilities . . . . 12 74 3.2.2. How the application can get the 5G network information 75 from ALTO . . . . . . . . . . . . . . . . . . . . . . 13 76 3.3. Use case 3: ALTO supporting applications on UEs . . . . . 14 77 3.3.1. Use case: Access-aware AEP selection from UE with 78 cascaded ALTO Servers . . . . . . . . . . . . . . . . 14 79 3.3.2. Scenario and assumptions . . . . . . . . . . . . . . 14 80 3.3.3. Missing ALTO information and features . . . . . . . . 15 81 4. Highlights on 3GPP Information Useful to ALTO . . . . . . . . 15 82 5. Gap analysis with Existing ALTO features . . . . . . . . . . 16 83 5.1. ALTO limits w.r.t. Cellular Network Information . . . . 16 84 5.2. ALTO Limits on network information transport: gap analysis 85 with ALTO SSE . . . . . . . . . . . . . . . . . . . . . . 16 86 6. Summarizing ALTO added value and gaps for cellular 87 networks . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.1. Summarizing ALTO added value to cellular use cases . . . 17 89 6.2. Summarizing new ALTO features needed to support cellular 90 use cases . . . . . . . . . . . . . . . . . . . . . . . . 17 91 6.2.1. ALTO Cellular Network Information . . . . . . . . . . 18 92 6.2.2. Efficient transport for ALTO Cellular Network 93 Information based on SSE . . . . . . . . . . . . . . 18 94 6.2.3. Time constraints on ALTO-provided Cellular Network 95 Information . . . . . . . . . . . . . . . . . . . . . 19 97 6.2.4. ALTO notifications to non-GBR as well as GBR 98 traffic . . . . . . . . . . . . . . . . . . . . . . . 20 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 10.2. Informative References . . . . . . . . . . . . . . . . . 20 105 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Introduction 110 The ALTO protocol has been defined as modern network traffic started 111 to convey a majority of user-initiated multimedia flows comprising 112 essentially video payload. The purpose of ALTO is to alleviate 113 network costs, congestion and load while maintaining application 114 performances. To this end, ALTO provides to applications that have a 115 choice among several endpoint location. This guidance consists for 116 ALTO in exposing a Network Map that is a subjective abstraction of 117 the Internet provider network. The Network Map is an arbitrary 118 provider-defined partition of the provider topology in zones that 119 have a human-readable identifier named PID and that gather network 120 endpoints that may be treated similarly, see RFC7285 sec 5.1. Among 121 these PIDs, the ALTO Cost Map defines abstracted network costs. 123 The design of ALTO is flexible and generic enough to support further 124 evolutions of application traffic and enable lightweight protocol 125 extensions. In particular as per section 5.2 of RFC7285, "There are 126 many types of addresses, such as IP addresses, MAC addresses, or 127 overlay IDs.", while the 7285 "document specifies (in Section 10.4) 128 how to specify IPv4/IPv6 addresses or prefixes." Likewise, the time 129 granularity of ALTO path costs was intended in the initial 130 requirements of RFC6708 to be in the order of days or more, 131 extensions such as RFC 8688 specifies the value encoding in floating 132 numbers, allowing thus smaller time interval durations. 133 Nevertheless, ALTO is by no means meant to provide information in 134 real-time. 136 In the first two WG charters, the ALTO applications and use cases 137 have focused on applications using network maps, cost maps defined on 138 IP Networks. Nevertheless, while the central use case in the base 139 protocol was peer-to-peer file sharing, the ALTO WG progressively 140 moved to CDN use cases, following thus the usage trend and the needs 141 of the service providers exposing their network abstraction. This 142 has produced extensions supporting finer grained information in terms 143 of network capabilities and time span. Applications are today 144 evolving to require more resources, performance, service presence and 145 reactivity. 147 Modern Applications now span endpoints in both fixed and cellular 148 networks. They are usually catered by Servers located at the edge or 149 within the core network. Servers view and manage IP flows while 150 Clients are associated to one or more flows defined according to 151 their hosting network technology. For example, a Client located in 152 3GPP defined cell is mapped to a so-called QoS flow, that may map to 153 one or more IP flows, either because the application involves say 154 voice or video, or because the user equipment (UE) is running several 155 applications simultaneously. These applications are also the most 156 Quality of Experience (QoE ) demanding ones. 158 The COVID period has witnessed frequent service degradation and 159 interruption in applications such as videoconferencing or gaming on a 160 mobile phone. The Servers need to be reactive enough to correctly 161 adapt their resources to the challenged users. To do so, they need 162 to have a reliable view of the network capabilities and bottlenecks, 163 while that view should cover application paths end to end and not 164 only at the user access network. There is a strong need for 165 application vendors to sustain user QoE, especially low latency and 166 acceptable throughput. Given the number of user flows, the 167 complexity of the network and sensitivity of user and network 168 information, the application server should get all and only what 169 information it needs. In other words, the network abstraction 170 exposed to applications must be reliable, preserve confidentiality, 171 suit the application needs and minimize the data exchange volume. 173 This draft emphasizes the importance of abstracted cellular 174 information, as the cell resides in the last IP hop, which is usually 175 the bottleneck. Therefore, last hop network information is critical. 176 It is important to have end to end information for apps having 177 cellular user footprint that covers both the edge and core Internet 178 and the access plus the cloud. The current networking SDOs such as 179 3GPP, ETSI, IETF do not cover all these areas simultaneously but 180 provide each a separate focused view. Note that it is the same for 181 Open Source organizations such as Open RAN (ORAN) or Facebook 182 sponsored - Open Computing Platform (OCP) providing in-band telemetry 183 info for DC networks. 185 This draft focuses on popular applications that have a user footprint 186 in cellular networks. It explores on one hand the requirements of 187 such applications in terms of network information, the capabilities 188 of 3GPP network information functionalities such as the Network 189 Exposure Function (NEF), and their the missing. On the other hand, 190 it explores what ALTO may potentially provide to compensate and 191 extend the scope of 3GPP information. The draft is thus motivated by 192 the following "gaps" between ALTO and 3GPP: 194 * Cellular information provided by 5G is limited in 2 ways: RAN 195 scope only, and QoS negotiation for only given type of traffic 196 (GBR), 198 * ALTO on the other hand is generic regarding the type of access. 199 However, it lacks small grain information and its dynamicity is 200 currently limited. Above all, the ALTO protocol and its 201 extensions are specified for IP networks. 203 1.1. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 1.2. Terminology 211 TO BE COMPLETED 213 QoS, ABR, RTT, GBR, XR/VR, AR, CGS 215 2. Motivation And First Considerations 217 2.1. Overview of challenges for applications on cellular networks 219 This section lists some challenges faced by applications running on 220 cellular networks that motivate the definition of ALTO-based network 221 topology exposure to improve application performance. 223 * New popular applications running on mobile networks: The current 224 ALTO protocol exposes endpoint addresses or path information. 225 ALTO was initially designed for P2P file or chunked data download 226 applications. Nowadays, P2P-like applications are no more widely 227 used. Instead, mobile internet got more popular, the price to buy 228 legal music/video/ebook files for download or streaming from a 229 dedicated service provider have dramatically reduced. 230 Consequently, there is little need to allow a user to change the 231 destination server address the path to destination server. The 232 major challenge now is to better support applications running on 233 the mobile internet. In 5G networking, selection of an 234 destination application server and related path is no major issue: 235 the 3GPP has defined a mechanism in [TS23.548] to let the 236 application change the Edge Compute server on the fly during the 237 download, where this change is automatic and transparent to the 238 user. A bigger issue, in 5G networks, is how to adapt the 239 application behavior, based on the data rate fluctuation in the 240 mobile network. 242 * 5G low-level network information too complex for application 243 developers: Too detailed radio level (low layer) parameters are 244 very hard to be understood by the application developers and are 245 thus very hard to be tested for the application development and 246 deployment. 248 * Notifications of RAN changes restricted to GBR traffic: In 5G 249 networks, notifications to CGS of QoS level change are currently 250 sent only for Guaranteed Bit Rate (GBR) traffic whereas they 251 should be used for non-GBR traffic as well. 253 2.2. Benefits expected from using ALTO to expose network topology to 254 applications 256 The first and fundamental benefit expected from ALTO is the ability 257 to expose simple and abstracted network topology information to 258 applications. An ALTO Client collocated with an application server 259 could easily get concise and safe information allowing adaptive 260 application behavior and QoE maintenance. Besides, with ALTO and its 261 handy JSON contents, application developers can take advantage of the 262 ALTO services to rapidly develop and update wireless applications 263 with less changes in their code. 265 Another important benefit is the ability of ALTO to support to 266 exposition to applications of the QoS supported by a path, given that 267 the supported QoS may vary over time. A fundamental ALTO service to 268 support the 5G would be the notification of different bit rates 269 supported in the access network. Providing such path QoS 270 notification to is of highest importance, as it allows the 271 applications to appropriately adapt their behavior, that is, in the 272 present case, their bitrate. Given that the path QoS can vary very 273 quickly, the information exchange must be fast, with simple terms, 274 while moderating the volume of exchanged information. 276 A first step in this direction is to introduce the definition of 277 three levels of path QoS supported for applications, that can be 278 defined in abstracted from 3GPP in ALTO terms. Each level may draw 279 specific requirements on the interaction between ALTO Client and ALTO 280 Server. 282 * Basic Level: for e.g. video streaming; normal data rate, and loose 283 latency requirements (e.g. network transport latency lower that 284 150ms)). In such case, the ALTO interaction can use the basic QoS 285 Notification Control (QNC) and alternative QoS profile (different 286 bit rate) defined in 5G. 288 * Medium Level: for e.g. conference call; high data rate (e.g. 289 higher than 5Mbps), but moderate vlatency requirement (e.g. 290 network transport lower than 150 ms). In this case the ALTO 291 interaction can use the QNC and small measurement time. 293 * Hard/complex Level: for e.g. cloud gaming, XR/VR services; high 294 data rate (e.g. higher than 5Mbps) and low latency (lower than 295 10ms for network transport, lower than 100ms end to end in service 296 level) services. More technologies are being studied in 3GPP R18. 297 e.g. new QoS Notification Type. 299 It is desirable to have the same data model in ALTO to express the 300 different QoS values or levels for different the use cases. 302 2.3. First considerations on ALTO information features for wireless 303 network 305 This draft does not aim at defining ALTO extensions to support 306 applications on cellular networks. This section lists some initial 307 considerations that would characterize such extensions. 309 Firstly, the use cases and associated needs of this draft do not 310 restrict to 5G cellular networks. They cover potential application 311 queries for ALTO network information that happen within the first IP 312 hop. Such needs may be true for 4G and 5G networks. 314 Currently in ALTO, the only way for an application to get a more 315 adequate QoS level is to use another path by selecting another 316 endpoint. In a wireless network, the application must use the same 317 path in which the QoS can change over time. The end user cannot 318 create or select another path during an application session. But 319 because of the physics of the wireless, the QoS of the wireless 320 connection may change quickly, so the application in the end user and 321 in the application server needs to detect the change of the QoS value 322 and adapt the application bit rate accordingly. Therefore, if the 323 ALTO service is used in a wireless network, we need to extend ALTO to 324 support only one path but with changes in the path cost or supported 325 QoS that occur very quickly, e.g. within seconds or sub-seconds. 327 A first architectural assumption is needed here for the ALTO Server 328 that would expose "below 1st hop" network information. We assume the 329 availability of a Local ALTO Server, that manages the information 330 covering the "below" first IP hop area delineated by the UEs and the 331 Packet Data Network (PDN). In the use cases of this draft a Local 332 ALTO Server may cover a 4G or 5G topology. It is queried by ALTO 333 Clients that may be associated to application functions in the 334 network edge or in end systems. It is not scalable to provide ALTO 335 information on paths from all UEs to all application endpoints in the 336 Internet. Therefore, it is desirable to use "cascaded" ALTO Servers, 337 where a local server covers the relevant access area and can, if 338 needed compose its information with a "core" ALTO Server that manages 339 information at an IP hop level or above. Such a solution is proposed 340 in sections 5.1 of [alto-cost-context] and section 2.3.3 of RFC 7971 341 on deployment cases. Thus: 343 * A Local ALTO Server (LAOS): covers a local and restricted part of 344 the network. It is typically located before the Internet gateway, 345 in the access network. For example, it can be collocated with the 346 NEF, as in the Cloud Gaming use case or with a gateway. It hosts 347 the information on the local 4G/5G network, covering the paths 348 between e.g. the UEs and the cells or the PGWs/UPFs. It may host 349 an ALTO Client that sends an ALTO request to a "core" ALTO Server, 350 covering the zone beyond the PGW/UPF. 352 * A "core" ALTO Server covers the whole ISP network view, at the IP 353 and beyond level, as it would if the "local ALTO Service" is not 354 available or deactivated. That is, it does not see the details 355 below the (UE, PGW/UPF) hop. 357 3. Example applications and use cases 359 This section presents emblematic examples of application use cases on 360 cellular networks. For each use case, it lists the network 361 information needed to maintain or improve application performances, 362 which one is available from 3GPP and from ALTO, which ones are 363 missing. Current examples applications are: Cloud gaming, 364 Conferencing, and use cases are divided in network-based decision 365 making and UE-based decision making. 367 3.1. Use case 1: rate adaptation for cloud VR/gaming 369 FOR FURTHER VERSIONS: Need artwork based on slide 1 of "ALTO 370 Recharter for Wireless Use cases-V6SR-2004" 372 5G is beginning to be commercialized globally since 2020, and there 373 is a great improvement regarding bandwidth enhancement and latency 374 reduction. Cloud-based interactive streaming applications such as 375 cloud Virtual Reality (VR) and cloud gaming are booming. 377 This type of applications requires low latency and highly reliable 378 transmission of motion tracking instructions from user to server in 379 the cloud, while the cloud is required to perform the rendering of 380 pictures per frame and deliver them to users with usually low latency 381 and high data rate. The required end-to-end transmission delay may 382 be as low as 20ms. The less the latency, the better the user QoE as, 383 for instance, a slight extra delay may cause user dizziness. The 384 downlink bandwidth normally depends on different parameter settings 385 such as DoF (Degree of Freedom), image resolution, frame rate, 386 adapted rendering and compression algorithm. For example, a high 387 definition with 1080p with 60 frames per seconds may require at least 388 20Mbps and ultra-high definition with 4K may require more than 389 40Mbps. 391 Cloud VR/gaming is regarded as one of killer applications as well as 392 major traffic contributor to cellular 5G networks. The major 393 advantages of cloud VR/gaming are easy and quick start since there is 394 no need to download and install a big volume of software in the user 395 device beforehand, and also it is cost effective and demands too 396 moderate processing load in the user device. Last, it is also 397 regarded as a more trusted solution. Thus, cloud gaming becomes a 398 competitive replacement for console gaming using cheaper PCs or 399 laptops. On one hand, the above cloud-based interactive applications 400 normally require high bandwidth and low latency, on the other hand, a 401 larger radio bandwidth implies larger variations since radio 402 resources are shared and competed by mobile users in a cell. 403 Therefore, the last mile radio link is viewed as the bottleneck of 404 the QoE. 406 To address this problem, the application usually estimates available 407 bandwidth based on application-level measurements such as traffic 408 throughput, RTT and latency. It then uses an adaptive bitrate (ABR) 409 mechanism to change the video encoding bitrate so as to match the 410 fluctuation of radio bandwidth. However, it is hard to accurately 411 estimate or predict user cellular link status only from the 412 application's perspective since only the cellular network has a full 413 understanding of all users' radio channel status, traffic 414 fluctuation, moving in and out of cells. Moreover, bandwidth 415 estimation based on application level traffic throughput statistics, 416 rather than radio channel capabilities may be inaccurate. 418 3.1.1. Application needs in information capabilities from network 420 Based on the above use case analysis, it would be beneficial if the 421 cellular network could inform the cloud streaming application on the 422 cellular network link status. The following approaches may be 423 considered. 425 * The application uses request/response to query the link status 426 from the cellular network for a specific user. This may cause 427 extra latency since two way signaling is required. 429 * The cellular network periodically reports network link status to 430 the application. This may cause extra signaling overhead if the 431 reporting period threshold is too frequent. 433 * The application uses a pub/sub-like mechanism, specifically, the 434 application may subscribe a certain condition (for example, 435 whether the QoS requirement is satisfied or significant QoS change 436 happens) for cellular network. As soon as the predefined 437 condition is fulfilled, the notification will be triggered 438 immediately and if the condition is not triggered, no signaling is 439 involved. Obviously, this approach is more cost effective from 440 signaling point of view and timely compared with request/response. 442 The application may inform the cellular network of the following 443 information ( not exhaustive list, new information may be added 444 later): 446 * QoS requirements of application, e.g., min and/or max bandwidth, 447 latency 449 * Significant QoS changes, e.g., 30% drop of bandwidth change 451 The cellular network link status may include the following 452 information (not exhaustive list, new information may be added 453 later): 455 * The available bandwidth and latency of the cellular network 457 * Whether QoS requirements of application are satisfied or not by 458 the radio network 460 * Whether significant QoS changes happen 462 3.1.2. Missing ALTO information and features 464 However, the current ALTO protocol and extensions are missing the 465 following information. 467 * The ALTO representation of the QoS of an application path requires 468 to represent the path endpoints. That is the path source and 469 destination. It the ALTO Endpoint Cost Service (ECS) is used, it 470 requires to indicate the endpoints. This is possible for the 471 destination, as it is the CGS, usually identified with an IP 472 address. However, the UE address would to be identified with an 473 identifier relating to cellular address. And the current ALTO 474 protocol only supports IP addresses. 476 * One possible workaround would be to identify a cell as a PID. 477 However, a PID MUST specify the network addresses it contains and 478 only IP addresses are supported. The path cost from a UE/Cell to 479 a CGS should be specific to a cell, but the IP address that is 480 provided to the UE is not. The ALTO Server should ensure that the 481 metric used to indicate the quality of the path to a CGS reflects 482 the specifics of a cellular network. 484 3.2. Use case 2: Video-conferencing applications 486 In the current context of massive teleworking, reliable video- 487 conferencing tools are of utmost importance. Poor experience or 488 service interruption occur more than often and may be caused by 489 factors impacting functions at both the Server end and the UE end. 491 In 2019, over 500 million active users were using online personal 492 live show services in China and there are 4 million simultaneous 493 online audience watching a celebrity's show. Low delay live show 494 requires the close interaction between application and network. 496 Compared with conventional broadcast services, this service is 497 interactive which means the audience can be involved and is able to 498 provide feedback to the anchorwoman or the anchorman of the game. A 499 gaming show has almost the same QoS requirements as 500 videoconferencing. It broadcasts the game playing to all the 501 audience, and also requires playing game interaction between the 502 anchor and the audience. A delay lower than 100ms is desired. If 503 the delay is too large, there will be undesirable degradation on user 504 experiences especially in a large-scale show. To lower the latency 505 and provide size-adjustable show content, the application also 506 requires QoS information of the transport layer of the wireless. 508 3.2.1. Application needs in information capabilities 510 The bit rate of radio link changes quickly. If the bit rate is 511 downgraded and the application still uses the previous bit rate to 512 send in the downlink to the user, the RAN will soon be in congestion 513 state, the user video will be frozen and user's QoE will be very bad. 514 So, the application needs to detect the bit rates of the transport 515 network. The DASH-based mechanism defined in MPEG can be used. 516 However, while the DASH based mechanism is normally for the file 517 download type video streaming, it is not suitable for the interactive 518 video. In the interactive video case, the transport can provide the 519 supported bit rate to the application, and application can adaptively 520 change its video bit rate down to the supported network bit rate and 521 there is no congestion anymore [TS 23.501]. The QoS Flow in the 5G 522 cellular network is established to transport the video streaming for 523 the conference, and application server may request the 5G network to 524 provide network information by the steps as described below, and 525 specified in [TS23.501]: 527 * The application requests the 5G network to notify the link status 528 and indicate whether the required GFBR (Guaranteed Flow Bit Rate) 529 can no longer be guaranteed or can be guaranteed again. 531 * The cellular network will notify the application that "GFBR can no 532 longer be guaranteed" if the radio link cannot provide the 533 required guaranteed bit rate. However, it does not specify the 534 amount of guaranteed bit rate. In this case, the cloud video 535 server (normally the medio server) will downgrade the video 536 streaming bit rate in order to avoid the video service being 537 frozen. However, since the video server does not know the 538 currently supported bit rate, the downgraded bit rate may be still 539 higher than the supported bit rate. After receiving the above 540 notification, the video service may still be frozen frequently. 541 If the video server downgrades the bit rate two much, the quality 542 of the video may be too downgraded and the user QoE becomes 543 unacceptable. 545 * The cellular network will notify the application that "GFBR can no 546 longer be guaranteed and the supported bit rate is XXX" if the 547 radio link cannot provide the required guaranteed bit rate, but 548 the cellular network can provide additional information of 549 supported guaranteed bit rate. Upon receiving this notification, 550 cloud video server can downgrade the video streaming bit rate 551 below the indicated bit rate. In such case, the user QoE does not 552 downgraded too much. 554 * The cellular network will notify the application that "GFBR can be 555 guaranteed again" if the radio link can provide the required 556 guaranteed bit rate again (for example, the user handovers to 557 another radio station). After receiving this notification, the 558 cloud video server can upgrade the video streaming bit rate to the 559 previous required guaranteed bit rate. In such case, the user QoE 560 can be recover to the best. 562 The application may inform the cellular network of the following, 563 given that the list below will be completed in the future: 565 * QoS requirements of application, e.g., the guaranteed bit rate, 566 the alternative guaranteed bit rate. 568 * The measurement time for the guaranteed bit rate, e.g. 2 seconds 569 (i.e. 2000ms) or 200/500 ms (to improve the response time, i.e. 570 more quickly to provide QoS Notification from the 5G RAN). 572 The cellular network link status exposed to the application may 573 include the following, given that the list below will be completed in 574 the future: 576 * "GFBR can no longer be guaranteed", 578 * "GFBR can no longer be guaranteed and the supported bit rate is 579 XXX", 581 * "GFBR can be guaranteed again". 583 All in all, the network should more quickly provide QoS Notification 584 to the application 586 3.2.2. How the application can get the 5G network information from ALTO 588 The application (i.e. the ALTO client) can use the restful API to 589 subscribe and be notified by the message from the ALTO Server, the 590 application can adaptively change its encoding scheme to make the bit 591 rate just below the provided network bitrate notified by the network. 592 Also, the application can be pushed to get the message from the ALTO 593 server using the SSE as defined in RFC 8895[RFC 8895]. 595 3.3. Use case 3: ALTO supporting applications on UEs 597 This section presents use cases where a UE runs an application with 598 the support of an ALTO Client. The application in the UE needs to 599 decide to which application endpoint (AEP) in the Internet to 600 connect. An AEP is assumed to be an application server for e.g. 601 content download, videoconferencing, or other applications for which 602 many servers are deployed. For now, the ALTO-based selection of an 603 AEP is usually done in the network, sometimes with the help of an 604 authoritative entity based on the cost or performance of the path 605 from the UE to the AEP. However, the capabilities of the access 606 network, in the first path IP hop, may highly impact the application 607 performance and therefore needs a deeper insight. The use cases in 608 this section illustrate how network abstraction within the first hop 609 can be beneficial to optimize application path performance. 611 3.3.1. Use case: Access-aware AEP selection from UE with cascaded ALTO 612 Servers 614 In this use case, a UE is located in a 4G or 5G network and may 615 connect via several access technologies, e.g. 4G/5G Cellular or WiFi. 616 It is assumed that the UE has subscribed to the same ISP for both 617 fixed and mobile access with a given Service Level Agreement SLA. 618 Users and ISPs tend usually prefer fixed or WiFi connection to 619 cellular, because it is cheaper, more performant and cellular 620 resources are limited. However, it is observed that in many places, 621 including some urban areas in countries with a good average network 622 infrastructure, the fixed network coverage is very poor and worse 623 than the cellular coverage, so that users need to connect via a cell 624 phone or a 4G/5G dongle. Sometimes also, MNOs and ISPs have spare 625 data resources or offer them for free or at low price to users, 626 depending on their SLA. For both parties, access-aware Endpoint 627 selection for users is thus beneficial. 629 The major QoE challenges in wireless network arise in the access 630 network, that is, in the first hop, between the UE and its one or 631 more associated packet data network gateways (PGW for 4G) or user 632 plane function (UPF for 5G). The path of a UE to its associated PGW/ 633 UPF impacts the path to the AEP and thus the application QoE. 634 Therefore, once the PGW/UPF has been selected and will stay 635 unchanged, it is beneficial to help the UE selecting between Cellular 636 and WiFi access. 638 3.3.2. Scenario and assumptions 640 The end to end path from the UE to the AEP is considered in 2 parts 642 * the path from the UE to the PDN, 643 * the path from the PDN to the AEP. 645 FOR FUTURE VERSIONS: ARTWORK ON SCENARIO 647 We assume the availability of multiple cascaded ALTO Servers, as 648 mentioned in section XXXX, to provide a (UE, AEP) path cost. In our 649 "cascaded" use case, we define 2 types of servers involved in 650 conveying the end to end ALTO (UE, AEP) path cost, as follows: 652 * A Local ALTO Server (LAOS): hosts the information restricted to 653 the local 4G/5G network, covering the paths between e.g. the UEs 654 and the cells or the PGWs/UPFs. It receives the ALTO request 655 issued by the local ALTO Client LAOC associated to the UE. It May 656 host an ALTO Client that can send an ALTO request to a "core" ALTO 657 Server, covering the zone beyond the PGW/UPF, if needed by the 658 application. It composes, when applicable, the response of the 659 "core" ALTO Server with its own response to the LAOC query to 660 obtain a better-informed end to end view of the application path. 662 * A "core" ALTO Server covers the whole ISP network view, as it 663 would if the "local ALTO Service" is not available or deactivated. 664 That is, it does not see the details below the (UE, PGW/UPF) hop. 666 3.3.3. Missing ALTO information and features 668 However, the ALTO information in the path between a UE and an AEP 669 currently provides a cost for one single path only. It does not 670 consider that multiple paths to the PGW/UPF are possible. Currently, 671 the access technology is accounted in RFC 7971 (on deployment cases) 672 in the last hop, to prefer selecting an AEP located in a fixed 673 network over an AEP located in a mobile network. One way to achieve 674 this is that ALTO provides a path cost that, for a given metric, 675 takes multiple values each depending on parameters such as access 676 technology and the access technology or SLA. 678 4. Highlights on 3GPP Information Useful to ALTO 680 This section lists the 3GPP information that can be used by ALTO. 681 Either as it comes in, with a minimal encapsulation, or as input to 682 an aggregated form. 684 In 3GPP specifications [TS23.501, 23.502, 23.503], the following 685 mechanisms have been specified to enable the interaction between AF 686 (application function) and NEF (network exposure function) from 687 network's perspective. 689 * Alternative QoS profiles, 690 * notification control. 692 The application inform the cellular network of the specific QoS 693 requirements, which may include a list of QRP( QoS requirement 694 parameters, such as min/max bandwidth) in a prioritized order. Such 695 requirements will be conveyed to the RAN and the RAN will always try 696 to fulfil the QoS requirement in the list with highest priority. And 697 in the meantime, whether QoS requirements is fulfilled or not in each 698 item of the list will be notified to the application timely. In 699 order to avoid too frequent signalling, it is assumed that RAN can 700 apply hysteresis (e.g., via a configurable time interval) to reduce 701 too much signalling overhead. On the other hand, the QoS values 702 within the list of QoS requirements are required not to be too close 703 to each other. 705 5. Gap analysis with Existing ALTO features 707 This section assesses the currently existing ALTO features against 708 the needs in network information and related transport capabilities 709 listed along with the use cases. 711 5.1. ALTO limits w.r.t. Cellular Network Information 713 ALTO is by design not expected to provide real time information. The 714 initial use cases were defined for cost maps conveying BGP-based path 715 costs. Later use cases for CDN and video download on individual end- 716 systems support finer grained network information. Nothing though 717 prevents ALTO information to be in minutes or sub-minutes frequency. 718 ALTO may convey values that are valid for a couple of seconds. 719 However, an interval of 2 seconds, in regard of a cellular, network 720 may be too large. 722 5.2. ALTO Limits on network information transport: gap analysis with 723 ALTO SSE 725 In RFC8895, ALTO Incremental Updates Using Server-Sent Events (SSE) 726 introduces a mechanism to allow an ALTO server to push updates to 727 ALTO clients to achieve two benefits: 729 * (1) updates can be incremental, in that if only a small section of 730 an information resource changes, the ALTO server can send just the 731 changes 733 * (2) updates can be immediate, in that the ALTO server can send 734 updates as soon as they are available. 736 SSE is a well-shaped pub/sub-like mechanism based on subscription, 737 which quite matches the requirements of proposed cellular use cased 738 in section XXXX, for example, cost effective and immediate. 739 Therefore, SSE can be used as a baseline for protocol extension of 740 cellular use cases. The following message flows can be reused. In 741 the following figure, init request of step 1 is used to subscribe QoS 742 requirements. Data update message of step 2a is used to notify 743 whether subscribed QoS requirements are satisfied or not. 745 FUTURE VERSIONS: ARTWORK ON SSE COMES HERE 747 Based on the existing SSE message flows, attributes should be 748 extended for each message flow for the proposed cellular use cases. 749 For example, subscribed QoS parameters and conditions in step 1, the 750 corresponding notification/data update in step 2a. 752 6. Summarizing ALTO added value and gaps for cellular networks 754 6.1. Summarizing ALTO added value to cellular use cases 756 * ALTO abstraction covers several network technologies 758 * ALTO abstraction covers several network scopes (RAN, edge, core, 759 transport, WAN) 761 * ALTO can aggregate network information over several technologies 762 and scopes 764 ALTO can provide end to end path information with insight on selected 765 parts. To our knowledge, standards covering the RAN, the edge, the 766 transport and the WAN (cite 3gpp, ETSI, others) provide a separate 767 network view to applications, if ever. There is therefore no way 768 currently for applications to get an integrated view, allowing more 769 informed decisions. Additionally, ALTO provides abstracted network 770 information, that protects operator confidentiality by exposing only 771 relevant information to applications. This last aspect adds 772 simplicity to the efficiency gained with network-aware decisions. 773 Simplicity all the more allows quick decisions, which is crucial in 774 cellular networks, that have high dynamics. 776 6.2. Summarizing new ALTO features needed to support cellular use cases 778 The uses cases presented in this draft are stressing the need for new 779 or extended ALTO features to convey cellular network information. 780 This section also lists a number of concerns raised, in some cases, 781 by the exposure of particular cellular information to third party 782 applications. Other needs may be identified as the cellular use 783 cases will be further investigated. 785 6.2.1. ALTO Cellular Network Information 787 ALTO features to represent identify a cell or a WiFi access point. 789 Abstracted and simplified metrics and costs for wireless networks: 790 ALTO Clients can request a list of supported values for a given set 791 of ALTO metrics. All these metrics are easy to be understood and to 792 be tested by the application developer and application platform 793 (service provider). Examples of useful metrics for our use cases 794 include: throughput/bit rate, latency, priority, error rate, Jitter. 795 Most of these metrics are being standardized in [alto-performance- 796 metrics]. However, their values need to be abstracted from the data 797 provided by the 5G network, typically via the NEF. 799 Other associated parameters associated to path cost metrics may be 800 useful. For instance, a new type of useful metric would be an 801 abstracted form of the time span to measure the bit rate. The 802 network also needs to expose the attributes of supported alternative 803 QoS. These include alternative throughput/bit rate, the time span to 804 measure the bit rate, latency, priority, error rate, Jitter and 805 associated priority. 807 Other abstracted and simplified parameters, thresholds or attributes 808 If radio level or low layer information are provided, a gateway is 809 needed to translate or map these information to the high level 810 terminology the ALTO Server. ALTO can then provide the abstracted 811 information to the application. This gateway can be implemented in 812 the southbound of the ALTO server and the gateway can be NEF or NWDA, 813 see reference to 3GPP TS XXx, TS23.288. 815 6.2.2. Efficient transport for ALTO Cellular Network Information based 816 on SSE 818 Improvements are necessary of the following ALTO SSE features: 820 FUTURE VERSIONS: ARTWORK ON EXTENDED SSE COMES HERE 822 Based on the existing SSE message flows, attributes should be 823 extended for each message flow for the proposed cellular use cases. 824 For step 1 in the procedure of "init request", the following 825 parameters may be included: 827 * User IP flow ID, or other information relating to UE IP address 829 * DL/UL capabilities 831 * A list of QoS requirements and conditions including: Priority, Min 832 bandwidth, Max bandwidth, delay threshold 834 For step 2a, the corresponding notification/data update can be 835 included regarding subscribed QoS parameters and conditions in step 836 1. 838 * User IP flow ID, or other information relating to UE IP address 840 * DL/UL capabilities 842 * A list of QoS requirements and conditions including: Priority, 843 current bandwidth or current delay 845 6.2.3. Time constraints on ALTO-provided Cellular Network Information 847 The main constraint when conveying ALTO information is speed. When a 848 significant change occurs in the RAN it should be ideally be notified 849 to an application in real-time. As this is not feasible with ALTO, 850 it is necessary to specify constraints such as: acceptable 851 notification delay, maximum delay beyond which the application 852 performance would get degraded, parameters defining an acceptable 853 degradation. 855 A typical example is as follows. The default measurement time for 856 the guaranteed bit rate is 2000ms, and the maximum rate of 857 notification is 1 time every 2 seconds in the case of data rate 858 fluctuation. This causes too much latency for low latency (lower 859 than 10ms) and/or high date rate (higher than 20mbps) services such 860 as cloud gaming. But it is acceptable for normal latency (e.g. 861 higher than 150ms) and normal data rate (lower than 5mbps) services. 862 The measurement time can be changed to 500ms or 200ms to improve the 863 response time, but the total number of notifications should not 864 increase too much. That is, the total number of notification times 865 should be the same level with the measurement time = 2000ms in a long 866 time span such as 1 hour. 868 As opposed to fixed networks for which ALTO was initially specified, 869 mobile networks, especially RAN have high traffic and network state 870 dynamics. ALTO is by no means expected to provide real-time 871 information. A careful design of 5G metrics abstraction and 872 hysteresis thresholds triggering ALTO notifications is necessary. 873 The resulting non-real time but highly dynamic ALTO information can 874 reduce the volume of data exchanged with the applications and in some 875 extent facilitate anticipation and reduce oscillations. 877 6.2.4. ALTO notifications to non-GBR as well as GBR traffic 879 In 5G networks, notifications to CGS are currently sent only for 880 Guaranteed Bit Rate (GBR) traffic whereas they should be for non-GBR 881 traffic as well. In practice nothing prevents an ALTO Server to do 882 so. To this end, the ALTO Server needs to have the necessary 883 identifiers of the IP flow that is impacted by the network conditions 884 (or QoS level) change. 886 7. Acknowledgements 888 8. IANA Considerations 890 This draft includes no request to IANA. 892 9. Security Considerations 894 FUTURE VERSIONS: TBC 896 10. References 898 10.1. Normative References 900 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, 904 DOI 10.17487/RFC2119, March 1997, 905 . 907 10.2. Informative References 909 [DOMINATION] 910 Mad Dominators, Inc., "Ultimate Plan for Taking Over the 911 World", 1984, . 913 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 914 DOI 10.17487/RFC2629, June 1999, 915 . 917 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 918 Text on Security Considerations", BCP 72, RFC 3552, 919 DOI 10.17487/RFC3552, July 2003, 920 . 922 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 923 IANA Considerations Section in RFCs", RFC 5226, 924 DOI 10.17487/RFC5226, May 2008, 925 . 927 Appendix A. Additional Stuff 929 This becomes an Appendix. 931 Authors' Addresses 933 Li Gang 934 China Mobile Research Institute 935 Beijing 936 China 938 Email: ligangyf@chinamobile.com 940 Sabine Randriamasy 941 Nokia Bell Labs 942 Nozay 943 France 945 Email: sabine.randriamasy@nokia-bell-labs.com 947 Chunshan Xiong 948 Tencent 949 Beijing 950 China 952 Email: chunshxiong@tencent.com