idnits 2.17.1 draft-krishna-mops-ar-use-case-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2020) is 1245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-mops-streaming-opcons-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOPS R. Krishna 3 Internet-Draft InterDigital Europe Limited 4 Intended status: Informational A. Rahman 5 Expires: May 3, 2021 InterDigital Communications, LLC 6 October 30, 2020 8 Media Operations Use Case for an Augmented Reality Application on Edge 9 Computing Infrastructure 10 draft-krishna-mops-ar-use-case-01 12 Abstract 14 A use case describing transmission of an application on the Internet 15 that has several unique characteristics of Augmented Reality (AR) 16 applications is presented for the consideration of the Media 17 Operations (MOPS) Working Group. One key requirement identified is 18 that the Adaptive-Bit-Rate (ABR) algorithms' current usage of 19 policies based on heuristics and models is inadequate for AR 20 applications running on the Edge Computing infrastructure. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 3, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Informative References . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 The MOPS draft, [I-D.ietf-mops-streaming-opcons], provides an 66 overview of operational networking issues that pertain to Quality of 67 Experience (QoE) in delivery of video and other high-bitrate media 68 over the Internet. However, as it does not cover the increasingly 69 large number of applications with Augmented Reality (AR) 70 characteristics and their requirements on ABR algorithms, the 71 discussion in this draft compliments the overview presented in that 72 draft [I-D.ietf-mops-streaming-opcons]. 74 Future AR applications will bring several requirements for the 75 Internet and the mobile devices running these applications. AR 76 applications require a real-time processing of video streams to 77 recognize specific objects. This is then used to overlay information 78 on the video being displayed to the user. In addition some AR 79 applications will also require generation of new video frames to be 80 played to the user. In order to run future applications with AR 81 characteristics on mobile devices, computationally intensive tasks 82 need to be offloaded to resources provided by Edge Computing. 84 Edge Computing is an emerging paradigm where computing resources and 85 storage are made available in close network proximity at the edge of 86 the Internet to mobile devices and sensors [EDGE_1], [EDGE_2]. 88 Adaptive-Bit-Rate (ABR) algorithms currently base their policy for 89 bit-rate selection on heuristics or models of the deployment 90 environment that do not account for the environment's dynamic nature 91 in use cases such as the one we present in this document. 92 Consequently, the ABR algorithms perform sub-optimally in such 93 deployments [ABR_1]. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Use Case 103 We now descibe a use case that involves an application with AR 104 systems' characteristics. Consider a group of tourists who are being 105 conducted in a tour around the historical site of the Tower of 106 London. As they move around the site and within the historical 107 buildings, they can watch and listen to historical scenes in 3D that 108 are generated by the AR application and then overlaid by their AR 109 headsets onto their real-world view. The headset then continuously 110 updates their view as they move around. 112 The AR application processes the scene that the walking tourist is 113 watching in real-time and identifies objects that will be targeted 114 for overlay of high resolution videos. It then generates high 115 resolution 3D images of historical scenes related to the perspective 116 of the tourist in real-time. These generated video images are then 117 overlaid on the view of the real-world as seen by the tourist. 119 Offloading to the remote Cloud is not feasible for applications with 120 AR characteristics as the end-to-end delays must be within the order 121 of a few milliseconds. In order to achieve such hard timing 122 constraints, computationally intensive tasks can be offloaded to Edge 123 devices. 125 4. Requirements 127 As discussed above an AR application requires offloading of its 128 components to resources provided by Edge Computing. These components 129 perform tasks such as real-time generation and processing of high- 130 quality video content that are too computationally intensive for the 131 mobile device. 133 In addition, such applications require high bandwidth and low jitter 134 to provide a high QoE to the user. Another consequence of running 135 such computationally intensive applications on AR devices such as AR 136 glasses is the excessive heat generated by the chip-sets that are 137 involved in the computation [DEV_HEAT_1]. Finally, the battery on 138 such devices discharges quickly when running such applications if 139 some processing is not off-loaded to the Edge Computing. 141 Note that the Edge device providing the computation and storage is 142 itself limited in such resources compared to the Cloud. So, for 143 example, a sudden surge in demand from a large group of tourists can 144 overwhelm that device. This will result in a degraded user 145 experience as their AR device experiences delays in receiving the 146 video frames. In order to deal with this problem, the client AR 147 applications will need to use Adaptive Bit Rate (ABR) algorithms that 148 choose bit-rates policies tailored in a fine-grained manner to the 149 resource demands and playback the videos with appropriate QoE metrics 150 as the user moves around with the group of tourists. 152 However, heavy-tailed nature of several operational parameters make 153 prediction-based adaptation by ABR algorithms sub-optimal[ABR_2]. 154 This is because with such distributions, law of large numbers works 155 too slowly, the mean of sample does not equal the mean of 156 distribution, and as a result standard deviation and variance are 157 unsuitable as metrics for such operational parameters [HEAVY_TAIL_1], 158 [HEAVY_TAIL_2]. Other subtle issues with these distributions include 159 the "expectation paradox" [HEAVY_TAIL_1] where the longer we have 160 waited for an event the longer we have to wait and the issue of 161 mismatch between the size and count of events [HEAVY_TAIL_1]. This 162 makes designing an algorithm for adaptation error-prone and 163 challenging. Such operational parameters include but are not limited 164 to buffer occupancy, throughput, client-server latency, and variable 165 transmission times.In addition, edge devices and communication links 166 may fail and logical communication relationships between various 167 software components change frequently as the user moves around with 168 their AR device [UBICOMP]. 170 Thus, once the offloaded computationally intensive processing is 171 completed on the Edge Computing, the video is streamed to the user 172 with the help of an ABR algorithm which needs to meet the following 173 requirements [ABR_1]: 175 o Dynamically changing ABR parameters: The ABR algorithm must be 176 able to dynamically change parameters given the heavy-tailed 177 nature of network throughput. This, for example, may be 178 accomplished by AI/ML processing on the Edge Computing on a per 179 client or global basis. 181 o Handling conflicting QoE requirements: QoE goals often require 182 high bit-rates, and low frequency of buffer refills. However in 183 practice, this can lead to a conflict between those goals. For 184 example, increasing the bit-rate might result in the need to fill 185 up the buffer more frequently as the buffer capacity might be 186 limited on the AR device. The ABR algorithm must be able to 187 handle this situation. 189 o Handling side effects of deciding a specific bit rate: For 190 example, selecting a bit rate of a particular value might result 191 in the ABR algorithm not changing to a different rate so as to 192 ensure a non-fluctuating bit-rate and the resultant smoothness of 193 video quality . The ABR algorithm must be able to handle this 194 situation. 196 5. Informative References 198 [ABR_1] Mao, H., Netravali, R., and M. Alizadeh, "Neural Adaptive 199 Video Streaming with Pensieve", In Proceedings of the 200 Conference of the ACM Special Interest Group on Data 201 Communication, (pp. 197-210), 2017. 203 [ABR_2] Yan, F., Ayers, H., Zhu, C., Fouladi, S., Hong, J., Zhang, 204 K., Levis, P., and K. Winstein, "Learning in situ: a 205 randomized experiment in video streaming", In 17th 206 {USENIX} Symposium on Networked Systems Design and 207 Implementation ({NSDI} 20), (pp. 495-511), 2020. 209 [DEV_HEAT_1] 210 LiKamWa, R., Wang, Z., Carroll, A., Lin, F., and L. Zhong, 211 "Draining our Glass: An Energy and Heat characterization 212 of Google Glass", In Proceedings of 5th Asia-Pacific 213 Workshop on Systems (pp. 1-7), 2013. 215 [EDGE_1] Satyanarayanan, M., "The Emergence of Edge Computing", 216 In Computer 50(1) (pp. 30-39), 2017. 218 [EDGE_2] Satyanarayanan, M., Klas, G., Silva, M., and S. Mangiante, 219 "The Seminal Role of Edge-Native Applications", In IEEE 220 International Conference on Edge Computing (EDGE) (pp. 221 33-40), 2019. 223 [HEAVY_TAIL_1] 224 Crovella, M. and B. Krishnamurthy, "Internet measurement: 225 infrastructure, traffic and applications", John Wiley and 226 Sons Inc., 2006. 228 [HEAVY_TAIL_2] 229 Taleb, N., "The Statistical Consequences of Fat Tails", 230 STEM Academic Press, 2020. 232 [I-D.ietf-mops-streaming-opcons] 233 Holland, J., Begen, A., and S. Dawkins, "Operational 234 Considerations for Streaming Media", draft-ietf-mops- 235 streaming-opcons-02 (work in progress), July 2020. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [UBICOMP] Bardram, J. and A. Friday, "Ubiquitous Computing Systems", 243 In Ubiquitous Computing Fundamentals (pp. 37-94). CRC 244 Press, 2009. 246 Authors' Addresses 248 Renan Krishna 249 InterDigital Europe Limited 250 64, Great Eastern Street 251 London EC2A 3QR 252 United Kingdom 254 Email: renan.krishna@interdigital.com 256 Akbar Rahman 257 InterDigital Communications, LLC 258 1000 Sherbrooke Street West 259 Montreal H3A 3G4 260 Canada 262 Email: Akbar.Rahman@InterDigital.com