idnits 2.17.1 draft-sprecher-mobile-tg-exposure-req-arch-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 88 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2015) is 3151 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC6994' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'RFC4413' is defined on line 485, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Jain 3 Internet-Draft A. Terzis 4 Intended status: Informational Google 5 Expires: March 12, 2016 N. Sprecher 6 S. Arunachalam 7 Nokia Networks 8 K. Smith 9 G. Klas 10 Vodafone 11 September 9, 2015 13 Requirements and reference architecture for Mobile Throughput Guidance 14 Exposure 15 draft-sprecher-mobile-tg-exposure-req-arch-02.txt 17 Abstract 19 Rapidly-varying conditions in a cellular network can cause problems 20 for the Transmission Control Protocol (TCP), which in turn can 21 degrade application performance. 23 This document presents the problem statement and proposes solution 24 principles. It specifies the requirements and reference architecture 25 for a mobile throughput guidance exposure mechanism that can be used 26 to assist TCP in cellular networks, ensuring better network 27 efficiency and enhanced service delivery performance. 29 The proposed mechanism can be applied to any content or TCP/IP based 30 application content delivery. This document describes the 31 applicability of the mechanism for Intelligent Video Acceleration 32 over cellular networks. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 12, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 71 1.4. Problem statement . . . . . . . . . . . . . . . . . . . . 3 72 1.5. Solution Principles . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Requirements on the Mobile Throughput Guidance Exposure 75 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.2. Security requirements . . . . . . . . . . . . . . . . . . 6 77 3. Reference Architecture . . . . . . . . . . . . . . . . . . . 7 78 4. Applicability to Mobile Video Delivery Optimization . . . . . 8 79 5. Manageability considerations . . . . . . . . . . . . . . . . 9 80 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 81 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 9.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 The following sub-sections present the problem statement and the 91 solution principles. 93 1.1. Contributing Authors 95 The editors gratefully acknowledge the following additional 96 contributors: Hannu Flinck, Helen Parsons, Peter Cosimini and Ram 97 Gopal. 99 1.2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 1.3. Acronyms and Abbreviations 107 HTTP Hypertext Transmission Protocol 108 IP Internet Protocol 109 LTE Long Term Evolution 110 RAN Radio Access Network 111 RTT Round Trip Time 112 TCP Transmission Control Protocol 113 UE User Equipment 115 1.4. Problem statement 117 Inefficient use of a cellular network's resources degrades 118 application performance, delivery of content and user experience. 120 Cellular networks are often required to deliver large, high bandwidth 121 files to end users, e.g from streaming media content providers. If 122 the available throughput from the Radio Access Network (RAN) to the 123 User Equipment (UE) falls below the bandwidth required then files are 124 delivered too slowly, resulting in a bad user experience. It may be 125 possible to take avoiding action and so limit the impact on the 126 network and the user experience. However to be able to do this in an 127 accurate and timely fashion, information on the available throughput 128 is required. 130 Internet media and file delivery are typically streamed or downloaded 131 today using Hypertext Transmission Protocol (HTTP) over the TCP. The 132 behavior of TCP assumes that network congestion is the primary cause 133 for packet loss and high delay. This may not be the case in cellular 134 networks where the bandwidth available for each UE can vary by an 135 order of magnitude within a few seconds due to changes in the 136 underlying radio channel conditions. Such changes can be caused by 137 the movement of devices or interference, as well as changes in system 138 load due to bursty traffic sources or when other devices enter and 139 leave the network. On the other hand, packet losses tend to be 140 sporadic and temporary; retransmission mechanisms at the physical and 141 link layers repair most packet corruptions. 143 1.5. Solution Principles 145 This document proposes that the cellular network could provide near 146 real-time information on "Throughput Guidance" to the TCP server; 147 this throughput guidance information would indicate the throughput 148 estimated to be available at the radio downlink interface (between 149 the RAN and the UE) for the TCP connection. 151 While the implementation details will vary according to the cellular 152 access network technology, the resource allocation can be abstracted 153 as the capacity of the "radio link" between the network and the UE. 154 For example, in the case of an LTE network, the number of physical 155 resource blocks allocated to a UE, along with the modulation scheme 156 and coding rate used, can be translated into radio link capacity in 157 Megabits per second (Mbps). It can also include the quality of the 158 "radio link" which is reported by the UE. 160 The TCP server can use this explicit information to inform several 161 congestion control decisions. For example: (1) selecting the initial 162 window size, (2) deciding the value of the congestion window during 163 the congestion avoidance phase, and (3) reducing the size of the 164 congestion window when the conditions on the "radio link" 165 deteriorate. In other words, with this additional information, TCP 166 does neither have to congest the network when probing for available 167 resource, nor rely on heuristics to reduce its sending rate after a 168 congestion episode. 170 The same explicit information can also be used to optimize 171 application behavior given the available resources. For example, 172 when video is encoded in multiple bitrates, the application server 173 can select the appropriate encoding for the network conditions. 175 Note that the throughput estimation for the upstream traffic between 176 the UE and the RAN, and the throughput of the network path between 177 the RAN and the server communicating with the UE are beyond the scope 178 of the document. 180 It is also important to note that the validity of the throughput 181 guidance and the distance between the originating server and the 182 cellular network (in terms of the number of Internet hops) are 183 inversely proportional. This is due to the fact that the latency 184 incurred at each hop increases the time that elapses between issuing 185 and consuming the guidance. 187 2. Requirements 189 The requirements set out in section 2.1 are for the behavior of the 190 mobile throughput guidance exposure mechanism and the related 191 functional elements. The related security requirements are specified 192 in section 2.2. 194 2.1. Requirements on the Mobile Throughput Guidance Exposure Mechanism 196 1. The throughput guidance information SHALL indicate the expected 197 available bandwidth in the downlink interface. Depending on the 198 solution mechanism, the information MAY be provided per TCP flow 199 or per user. If the solution mechanism supports both options, 200 then granularity SHOULD be configurable. 202 2. The throughput guidance information SHALL be provided for TCP 203 based traffic. 205 3. A functional element, residing in the RAN and acting as 206 Throughput Guidance Provider, SHOULD supply the TCP server a 207 near real-time indication (in sub-seconds) on the throughput 208 estimated to be available at the radio downlink interface (i.e., 209 mobile throughput guidance information). It SHOULD keep up with 210 the rapid changes in the radio network conditions, the network 211 traffic and the user movement, in order to provide the most 212 accurate guidance information. 214 4. The introduction of the Throughput Guidance exposure mechanism 215 SHALL NOT require any update to the TCP client software. 217 5. The mobile throughput guidance exposure mechanism SHALL work 218 when the user traffic is end-to-end encrypted (e.g., HTTPS, 219 etc.). This requirement is compliant with the IAB Statement on 220 Internet Confidentiality (see [IAB_Statement]), saying that the 221 IAB "strongly encourage developers to include encryption in 222 their implementations, and to make them encrypted by default. 223 We similarly encourage network and service operators to deploy 224 encryption where it is not yet deployed, and we urge firewall 225 policy administrators to permit encrypted traffic.". 227 6. The mobile throughput guidance exposure mechanism SHALL NOT 228 adversely impact the behavior of the TCP flows (e.g., it SHOULD 229 NOT cause an increase in retransmissions or degradation in 230 performance, etc.). 232 7. The throughput guidance information SHALL be opaque to the 233 intermediate elements between the Throughput Guidance Provider 234 and the TCP server. The intermediate elements SHOULD NOT modify 235 or remove the throughput guidance information. 237 8. The TCP server MAY reside within the mobile operator's network 238 (behind the mobile core network) or in the Internet. 240 9. The TCP server MAY use the mobile throughput guidance 241 information to assist TCP. 243 10. It SHOULD be possible for the TCP server to provide the exposed 244 mobile throughput guidance information to an authorized higher 245 layer application. The application may use the mobile 246 throughput guidance information to optimize its behavior. 248 11. The Throughput Guidance Provider SHOULD provide the mobile 249 throughput guidance information periodically, starting from the 250 initiation of the flow. 252 12. The frequency (in milliseconds) at which mobile throughput 253 guidance needs to be exposed SHALL be configurable. 255 13. The mobile Throughput Guidance Provider SHALL be able to supply 256 mobile throughput guidance information to more than one TCP 257 server simultaneously, with independent configurable parameters 258 for each server. 260 14. There SHOULD be a mechanism to configure the Mobile Throughput 261 Guidance Provider with a list of TCP flows for which mobile 262 throughput guidance information shall be exposed. 264 15. The mobile throughput guidance exposure mechanism SHOULD ensure 265 backward compatibility. Normal TCP processing at the TCP server 266 SHOULD be performed if the TCP server does not recognize the 267 throughput guidance information. 269 16. The mobile throughput guidance exposure mechanism MUST be 270 extensible, ensuring that additional information can be provided 271 in the future in a non-disruptive, backward-compatible way. 273 2.2. Security requirements 275 1. A trustful relationship between the Mobile Throughput Provider 276 and the TCP server SHOULD be formed before any information is 277 exposed. 279 2. There SHOULD be a mechanism to configure the Mobile Throughput 280 Guidance Provider with a list of destinations to which throughput 281 guidance should be provided. 283 3. The identity of the Mobile Throughput Guidance Provider SHALL be 284 explicitly known to the TCP server which receives the 285 information. The TCP server SHALL be able to authenticate the 286 identity of the Mobile Throughput Guidance Provider. The Mobile 287 Throughput Guidance Provider MUST NOT reveal any other identity 288 or address of network elements that can compromise the security 289 of the network. 291 4. The mobile throughput guidance information SHOULD be secured to 292 ensure confidentiality and integrity. 294 5. There SHOULD be a mechanism to configure the required security 295 level and parameters for the encryption and the authentication if 296 supported. 298 6. The exposure of the Mobile throughput guidance information SHALL 299 NOT introduce any additional security threats and privacy 300 concerns to the mobile operator's network, the Internet and the 301 users. 303 7. The throughput guidance SHOULD be treated only as an estimate to 304 the optimization algorithm running at the TCP server. The TCP 305 server that receives this information SHOULD NOT assume that it 306 is always accurate and up to date. Specifically, the TCP server 307 SHOULD check the validity of the information received and if it 308 finds it erroneous it SHOULD discard it and possibly take other 309 corrective actions (e.g., discard all future throughput guidance 310 information from a particular IP prefix). 312 3. Reference Architecture 314 Figure 1 below, depicts the functional elements and their interfaces 315 that comprise the mobile network guidance solution (based on the 316 requirements for mobile throughput guidance). 318 A Throughput Guidance Provider functional element signals to the TCP 319 server the information on the (near-real time) throughput estimated 320 to be available at the radio downlink interface. The TCP server 321 resides within the mobile operator's network or in the Internet. 323 Note that the Throughput Guidance Provider functional element and the 324 TCP server can belong to the same Administrative System (AS) or to 325 different Administrative Systems. 327 The TCP server MAY use the information to optimize the TCP behavior. 328 The information MAY also be used by the application to adapt its 329 behavior accordingly and to optimize service delivery performance. 331 TCP flow behaviour based on 332 +-+-+-+-+-+-+-+ Throughput Guidance Information +-+-+-+-+-+-+-+ 333 | | <---------------------------------------- | | 334 | TCP client | +-+-+-+-+-+-+-+-+-+-+-+ | TCP Server | 335 | | | Througput Guidance | (x) | | 336 | | | Provider | ----------> | | 337 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 339 UE <--------------- RAN -------------------> x = Mobile Thourghput 340 Guidance Signaling 342 Mobile Throughput Guidance Reference Architecture 344 Figure 1 346 The information source and the algorithm used by the Throughput 347 Guidance Provider to calculate the throughput guidance are beyond the 348 scope of this document. 350 The TCP server MAY use the throughput guidance information to assist 351 TCP in any of the following ways: 353 o Determine the size of the initial congestion window 355 o Determine when to exit the slow start phase 357 o Determine the size of the congestion window during the congestion 358 avoidance phase 360 o Determine the size of the window after a congestion event 362 4. Applicability to Mobile Video Delivery Optimization 364 The mobile throughput guidance exposure mechanism applies to mobile 365 video delivery optimization. 367 In this use case the Throughput Guidance Provider sends to the video 368 server throughput guidance information for a TCP flow. The video 369 server may use this information to assist TCP congestion control 370 decisions, for example in selecting the initial congestion window 371 size, and adjusting the size of the congestion window when the 372 conditions on the radio link change. In other words, with this 373 additional information, TCP does not need to overload the network 374 when probing for available resources, nor does it need to rely on 375 heuristics to reduce its sending rate after a congestion episode. 376 Slow start and buffering of content delivery can be eliminated. 378 The same information may also be used to ensure that the application 379 level coding matches the estimated capacity at the radio downlink. 381 The aim of all of these improvements is to enhance the end user's 382 quality of experience. For example, the content's time-to-start as 383 well as video buffering occurrences can be reduced, the utilization 384 of the radio network's resources and its throughput can be optimized, 385 etc. 387 5. Manageability considerations 389 Manageability of mobile throughput guidance exposure will be 390 discussed in the solution documents. Section 2 specifies a set of 391 requirements on the management of the mobile throughput guidance 392 exposure functional elements and protocol operation. 394 6. Security considerations 396 The exposure of mobile throughput guidance information from the 397 cellular network to the TCP server introduces a set of security 398 considerations. 400 As per requirement #3 in section 2.2, the TCP server SHALL be able to 401 authenticate the identity of the Mobile Throughput Guidance Provider. 402 The Mobile Throughput Guidance Provider MUST NOT reveal any other 403 identity or address of network elements that can compromise the 404 security of the network. 406 Furthermore, the throughput guidance information should be treated 407 only as an estimate to the congestion control algorithm running at 408 the transport endpoint. The endpoint that receives this information 409 should not assume that it is always correct and accurate. 410 Specifically, endpoints should check the authenticity and integrity 411 of the information received and if they find it erroneous they should 412 discard it and possibly take other corrective actions (e.g., discard 413 all future throughput guidance information from a particular IP 414 prefix). 416 One way to check if the throughput guidance information overestimates 417 the capacity available on the radio link is to check whether any 418 packet losses or other signs of congestion (e.g., increasing RTT) 419 occur after the guidance is used. Notably, the same mechanism can be 420 used to deal with bottlenecks in other parts of the end-to-end 421 network path. To check if the throughput guidance underestimates the 422 available network capacity, the source can periodically attempt to 423 send faster and then check for signs of congestion. 425 Section 2 above, specifies a set of requirements on the mobile 426 throughput guidance exposure protocol to ensure secured communication 427 and operation. 429 7. IANA considerations 431 This requirements and architecture document does not introduce any 432 requests for IANA actions. 434 8. Acknowledgements 436 We would like to thank Peter Szilagyi, Meir Cohen and Csaba Vulkan 437 for conversations on these issues. 439 9. References 441 9.1. Normative References 443 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 444 RFC 793, DOI 10.17487/RFC0793, September 1981, 445 . 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, 449 DOI 10.17487/RFC2119, March 1997, 450 . 452 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 453 RFC 6994, DOI 10.17487/RFC6994, August 2013, 454 . 456 9.2. Informative References 458 [I-D.narten-iana-considerations-rfc2434bis] 459 Narten, T. and H. Alvestrand, "Guidelines for Writing an 460 IANA Considerations Section in RFCs", draft-narten-iana- 461 considerations-rfc2434bis-09 (work in progress), March 462 2008. 464 [IAB_Statement] 465 "IAB Statement on Internet Confidentiality", November 466 2014, . 469 [MEC_White_Paper] 470 "Mobile-Edge Computing - Introductory Technical White 471 Paper", September 2014, 472 . 476 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 477 DOI 10.17487/RFC2629, June 1999, 478 . 480 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 481 Text on Security Considerations", BCP 72, RFC 3552, 482 DOI 10.17487/RFC3552, July 2003, 483 . 485 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 486 DOI 10.17487/RFC4413, March 2006, 487 . 489 Authors' Addresses 491 Ankur Jain 492 Google 493 1600 Amphitheatre Parkway 494 Mountain View, CA 94043 495 US 497 Phone: +1-925-526-5879 498 Email: jankur@google.com 500 Andreas Terzis 501 Google 502 1600 Amphitheatre Parkway 503 Mountain View, CA 94043 504 US 506 Phone: +1-650-214-5270 507 Email: aterzis@google.com 508 Nurit Sprecher 509 Nokia Networks 510 Hod HaSharon 511 IL 513 Phone: +97297751229 514 Email: nurit.sprecher@nsn.com 516 Swaminathan Arunachalam 517 Nokia Networks 518 Irving 519 FUS 521 Phone: +19723303204 522 Email: swaminathan.arunachalam@nsn.com 524 Kevin Smith 525 Vodafone 526 One Kingdom Street, Paddington Central 527 London W2 6BY 528 UK 530 Email: kevin.smith@vodafone.com 532 Guenter Klas 533 Vodafone 534 One Kingdom Street, Paddington Central 535 Newbury RG14 2FN 536 UK 538 Email: kguenter.klas@vodafone.com 540 Hannu Flinck 541 Nokia Networks 542 Helsinki 543 FI 545 Phone: +358504839522 546 Email: hannu.flinck@nsn.com 548 Helen Parsons 549 Google 550 1600 Amphitheatre Parkway 551 Mountain View, CA 94043 552 US 554 Email: helenparsons@google.com 556 Peter Cosimini 557 Vodafone 558 Vodafone House, The Connection 559 Newbury, RG14 2FN 560 UK 562 Email: peter.cosimini@vodafone.com 564 Ram Gopal 565 Nokia Networks 566 Mountain View 567 US 569 Phone: +17815264572 570 Email: ram.gopal@nsn.com