idnits 2.17.1 draft-flinck-mobile-throughput-guidance-04.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 (March 13, 2017) is 2573 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC4413' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 656, 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: 1 error (**), 0 flaws (~~), 6 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: September 14, 2017 H. Flinck 6 N. Sprecher 7 S. Arunachalam 8 Nokia Networks 9 K. Smith 10 Vodafone 11 V. Devarapalli 12 R. Bar Yanai 13 Vasona Networks 14 March 13, 2017 16 Mobile Throughput Guidance Inband Signaling Protocol 17 draft-flinck-mobile-throughput-guidance-04.txt 19 Abstract 21 The bandwidth available for end user devices in cellular networks can 22 vary by an order of magnitude over a few seconds due to changes in 23 the underlying radio channel conditions, as device mobility and 24 changes in system load as other devices enter and leave the network. 25 Furthermore, packets losses are not always signs of congestion. The 26 Transmission Control Protocol (TCP) can have difficulties adapting to 27 these rapidly varying conditions leading to inefficient use of a 28 cellular network's resources and degraded application performance. 29 Problem statement, requirements and the architecture for a solution 30 is documented in [Req_Arch_MTG_Exposure]. 32 This document proposes a mechanism and protocol elements that allow 33 the cellular network to provide near real-time information on 34 capacity available to the TCP server. This "Throughput Guidance" 35 (TG) information would indicate the throughput estimated to be 36 available at the radio downlink interface (between the Radio Access 37 Network (RAN) and the mobile device (UE)). TCP server can use this 38 TG information to ensure high network utilization and high service 39 delivery performance. The document describes the applicability of 40 the proposed mechanism for video delivery over cellular networks; it 41 also presents test results from live operator's environment. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 14, 2017. 60 Copyright Notice 62 Copyright (c) 2017 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 79 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 81 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.5. Assumptions and Considerations for the Solution . . . . . 4 83 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 8 85 2.2. Authentication . . . . . . . . . . . . . . . . . . . . . 10 86 3. Applicability to Video Delivery Optimization . . . . . . . . 10 87 3.1. Test Results . . . . . . . . . . . . . . . . . . . . . . 11 88 4. Manageability considerations . . . . . . . . . . . . . . . . 12 89 5. Security considerations . . . . . . . . . . . . . . . . . . . 12 90 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 8.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 98 1. Introduction 100 The problem statement related to the behavior of the TCP in cellular 101 networks is provided in [Req_Arch_MTG_Exposure]. That same document 102 specifies the requirements, reference architecture and proposed 103 solution principles for a mobile throughput guidance exposure 104 mechanism that can be used to assist TCP in cellular networks, 105 ensuring high utilization and high service delivery performance. 107 This document presents a set of considerations and assumptions for 108 the development of a solution. It specifies a protocol that 109 addresses the requirements and the architecture stated in the 110 [Req_Arch_MTG_Exposure]. This document describes also the 111 applicability of the proposed mechanism to video delivery over 112 cellular networks with test results from live production environment. 114 1.1. Contributing Authors 116 The editors gratefully acknowledge the following additional 117 contributors: Peter Szilagyi/Nokia, Csaba Vulkan/Nokia, Ram Gopal/ 118 Nokia, Guenter Klas/Vodafone and Peter Cosimini/Vodafone. 120 1.2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 1.3. Acronyms and Abbreviations 127 This document uses the following acronyms: 129 ECGI E-UTRAN Cell Global Identifier format 130 ECN Explicit Congestion Notification 131 HMAC Hash-based Message Authentication Code 132 HTTP Hypertext Transfer Protocol 133 HTTPS Hypertext Transfer Protocol Secure 134 IP Internet Protocol 135 IV Initialization Vector 136 LTE Long Term Evolution 137 MTG Mobile Throughput Guidance 138 RAN Radio Access Network 139 RCTP RTP Control Protocol 140 RTT Round Trip Time 141 SACK Selective Acknowledgement 142 TCP Transmission Control Protocol 143 TCP-EDO TCP Extended Data option 144 TG Throughput Guidance 145 UE User Equipment 147 1.4. Definitions 149 Throughput Guidance Provider: 151 A functional element that has access to the radio network 152 information and signals to the TCP server, information about the 153 (near-real time) throughput estimated to be available to a UE at 154 the radio downlink interface 156 1.5. Assumptions and Considerations for the Solution 158 This document specifies a solution protocol that is complies with the 159 requirements and architecture specified in [Req_Arch_MTG_Exposure]. 160 The protocol is used by the cellular network to provide throughput 161 guidance information to the TCP server; this information indicates 162 the throughput estimated to be available at the radio downlink 163 interface for the TCP connection. The protocol allows the 164 information to be provided in near real time in situations where the 165 network conditions are changing frequently or the user is moving. 167 While the implementation details can vary according to the access 168 technology, the resource allocation is abstracted as the capacity of 169 the "radio link" between the RAN and the UE. For example, in the 170 case of an LTE network, the number of physical resource blocks 171 allocated to a UE, along with the modulation scheme and coding rate 172 used, can be translated into radio link capacity in Megabits per 173 second (Mbit/s). From the derived UE's total throughput and with the 174 UE's TCP flow information, Throughput guidance for the TCP connection 175 can be computed. 177 The TCP server can use this explicit information to inform several 178 congestion control decisions. For example: (1) selecting the initial 179 congestion window size, (2) deciding the value of the congestion 180 window during the congestion avoidance phase, and (3) adjusting the 181 size of the congestion window when the conditions on the "radio link" 182 change. In other words, with this additional information, TCP 183 neither has to congest the network when probing for available 184 resources (by increasing its congestion window), nor rely on 185 heuristics to decide how much it should reduce its sending rate after 186 a congestion episode. 188 The same explicit information can also be used to optimize 189 application behavior given the available resources. For example, 190 when video is encoded in multiple bitrates, the application server 191 can select the highest encoding rate that the network can deliver. 193 This solution specified in this document also satisfies the following 194 assumptions and considerations: 196 o The end-to-end traffic is delivered via HTTP. 198 o The end-to-end traffic is encrypted (through HTTPS), thus HTTP 199 header enrichment cannot be used by intermediate elements between 200 the client and the server. 202 o TCP is used to deliver the HTTPS traffic. 204 o The Real-time Transport Protocol (RTP) network protocol is not 205 used for traffic delivery. 207 The protocol specified in this document assumes that a trustful 208 relationship between the Throughput Guidance Provider and the TCP 209 server has been formed using the means discussed in the Security 210 considerations section. 212 The solution in this document satisfies the considerations and the 213 assumptions presented above, and proposes an in-band exposure 214 mechanism where the throughput guidance information is added to the 215 TCP headers of the relevant upstream packets. HTTP and TCP are the 216 most prevalent protocols in the Internet, used even by the most 217 popular streaming application. Throughput guidance at TCP level can 218 be shared among multiple applications; it is not limited to any 219 particular application level optimization only but it offers a 220 generic approach that works even if application level end-to-end 221 encryption, such as HTTPS, is applied. 223 In particular, the Throughput Guidance Providers adds the throughput 224 guidance information to the Options field of the TCP header (see RFC 225 0793 [RFC0793]) of packets from the TCP client to the TCP server. An 226 in-band mechanism is proposed because it does not require a separate 227 interface, reference value, or correlation mechanism that would be 228 needed with out of band approaches such as with RCTP that is limited 229 to only certain types of applications. Furthermore, an in-band 230 mechanism can keep up with the rapid changes in the underlying radio 231 link throughput. Unlike existing mechanisms such as ECN, where an 232 ECN- aware router sets a mark in the IP header in order to signal 233 impending congestion (see [RFC3168]). The proposed scheme provides 234 explicit information, (termed "Throughput Guidance") about the 235 estimated throughput available for the TCP connection at the radio 236 link between the RAN and the UE. 238 Note that once standardized and implemented, TCP Extended Data option 239 (TCP-EDO) can be used to carry the throughput guidance information as 240 specified in [tcp-edo] and simplify the use of the TCP Option fields 241 by extending the space available for TCP options. Currently the TCP- 242 EDO is still work in progress and not available in production. 243 Therefore, the use of TCP-EDO to carry throughput guidance is left 244 for the later drafts. 246 2. Protocol 248 This section describes the protocol mechanism and the message format 249 that needs to be communicated from the RAN to the TCP remote 250 endpoint. We describe the protocol mechanism and message format for 251 throughput guidance. The protocol mechanism is defined in an 252 extensible way to allow additional information to be specified and 253 communicated. The protocol specification is based on the existing 254 experiments and running code. It is recommended to insert the 255 throughput guidance information to the TCP segments that flow from 256 client to server (see reasoning in "Assumptions and Considerations" 257 section). Most of the time, TCP segments are ACK packets from a 258 client to the server and hence packets are unlikely to be fragmented. 259 However, the described protocol solution can deal with fragmentation. 261 The Mobile Throughput Guidance Signaling message conveys information 262 on the throughput estimated to be available at the down link path for 263 a given TCP connection. The information is sent to the uplink end- 264 point of the connection (i.e, the TCP server). The TCP server MAY 265 use this information to adapt TCP behavior and to adjust application- 266 level behavior to the link conditions as defined in 267 [Req_Arch_MTG_Exposure]. 269 A good example is a content optimizer or a cache that can adapt the 270 application-level coding to match the indicated downlink radio 271 conditions. As radio link conditions may change rapidly, this 272 guidance information is best carried in-band using TCP options 273 headers rather than through an out-of-band protocol. 275 Using the TCP options to carry throughput guidance associates the 276 guidance information with an ongoing TCP connection and explicitly 277 avoids separate session identification information. The proposed 278 mechanism neither impacts the TCP state machine nor the congestion 279 control algorithms of the TCP protocol. 281 The Options field enables information elements to be inserted into 282 each packet with a 40-byte overall limit; this needs to be shared 283 with the standardized and widely-used option elements, such as the 284 TimeStamp and SACK. (Use of TCP-EDO will lift this constraint once 285 available and deployed). The TCP Options field uses a Kind-Length- 286 Value structure that enables TCP implementations to interpret or 287 ignore information elements in the Options field based on the Kind. 289 In this draft, we define a message format for encoding information 290 about the estimated capacity of a radio access link between the RAN 291 and the UE which is traversed by a TCP connection. The intention is 292 to define a generic container to convey in-band information within 293 the limited TCP Option space with optional authentication 294 capabilities. This document conveys throughput guidance information. 295 Additional information can be specified in future. 297 The Throughput Guidance Provider functional element inserts Mobile 298 Throughput Guidance TCP options only if there is enough space in the 299 TCP header. The Throughput Guidance Provider has access to the radio 300 network information and is typically co-located with the RAN 301 functionality. 303 The Throughput Guidance information must be delivered in a secure 304 way, such than an intermediate node cannot modify it. The 305 information can be provided as plain text in a secure and closed 306 network. In other cases, the information should be authenticated 307 (between the Throughput Guidance Provider and the TCP server). An 308 acceptable level of authentication (according to best common 309 practices) may require more data than fits into a single TCP header 310 (maximum of 40 bytes if no other options are present). As described 311 below, fragmenting information across multiple packets will be used 312 if such is the case. 314 Two transfer modes are defined to deal with security of exchanged 315 throughput guidance information in this document; namely, plain-text 316 mode and authenticated mode. A third mode, encryption with 317 authentication mode, is equally feasible and may be described in a 318 future revision of this protocol. The flags field indicate which 319 mode is used. 321 2.1. Message Format 323 Mobile Throughput Guidance Signaling uses the common TCP options 324 structure as in [RFC0793] with experimental identifier as defined in 325 [RFC6994]. The followign defines the message format: 327 0 1 2 3 328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | kind | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | ExID | Ver |Resvd|Frag |P|T| 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Seq number | SBR | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | CL |KeyIndx| Auth MAC (20 bytes) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 1 341 Kind: 343 Code point 253 for Experimental Option for 16-bit ExID [RFC6994]. 344 The size of this field is 1 byte. 346 Length: 348 A 1-byte field, length of the option in bytes as defined in 349 RFC793. 351 ExID: 353 Two bytes Experimental Identifier according to [RFC6994]. Code 354 point 0x6006. 356 Ver: 358 Version of the protocol, set to 1. 360 Flags: 362 One byte of MTG protocol flag field as defined below. 364 0 1 2 3 4 5 6 7 365 +-+-+-+-+-+-+-+-+ 366 |Resvd|Frag |P|T| 367 +-+-+-+-+-+-+-+-+ 369 Flag field of common Kind-Lenght-Value header 371 Figure 2 373 Frag: 375 Three bits that provide information about how to reassemble 376 information if fragmented into multiple packets. If no 377 fragmentation across multiple TCP packet headers is needed, these 378 bits are set to zero. Otherwise, Frag is a counter starting from 379 1 and incremented by 1 for each subsequent packet of the same type 380 (see P- and T-bits below). For the last fragment, the Fragment is 381 always 7 (binary 111) to indicate that the information is 382 complete. 384 P and T bits: 386 These two bits encode the packet type: Plaintext (P=0, T= 0), 387 Cipher text (P=0, T=1), Nonce (IV) (P=1, T=0) or Authentication 388 (P=1, T=1). For Plaintext, the Fragment bits are always zero. 390 Seq Number: 392 16-bit sequence number to protect against replay attacks 394 SBR: 396 Suggested bit rate for the data session in Mbps. The 12 most 397 significant bits are used for the integer value while the bottom 4 398 bits correspond to the decimal portion of the throughput value. 400 CL: 402 Cell Congestion Level (0, 1, 2, 3). A 4-bit field that indicates 403 the current cell congestion level. "0" indicates no congestion and 404 "3" indicates high congestion value. 406 Key Index: 408 A 4-bit field to identify the key used for integrity protection. 410 Auth MAC: 412 20 bytes of MAC that protects the TCP option 414 2.2. Authentication 416 Authentication covers the entire TCP option, exlcuding the Flags 417 field and the Auth MAC field. The authentication uses HMAC codes 418 (e.g. HMAC- SHA2-224), 128 bits (16 bytes) key size, 256 bits (32 419 bytes) digest size. Multiple keys (at most 256) for authentication 420 with the same information receiver can be used. Truncation is 421 possible but at least 160 bits (20 bytes) must be used from the 422 digest to meet the typical security level of mobile networks. 424 Authentication takes a key, the input (arbitrary length) and produces 425 a 32 byte long digest, which is truncated to 20 bytes (keeping the 426 most significant bytes). The HMAC algorithm and truncation can be 427 negotiated via key management (out of scope of this document). 429 The order in which the fields are included into the message 430 authentication code is the same as the order in which the bytes 431 appear in the message format. 433 In case the option packets used as input to the HMAC are fragmented 434 into multiple TCP headers, they are processed so that headers with 435 cipher text option are processed first, followed by IV/Nonce option 436 packets. 438 The options containing the result of the HMAC are marked by setting 439 both P- and T-bits of the flag-field to one. Key Index is set to 440 point to the used authentication key, followed by the resulting 441 authentication code. If the option doesn't fit into the free option 442 space in the TCP header, it is fragmented across multiple TCP headers 443 in the same way as the cipher text options. 445 3. Applicability to Video Delivery Optimization 447 The applicability of the protocol specified in this document to 448 mobile video delivery optimization has been evaluated and tested in 449 different network load scenarios. 451 In this use case, TCP traffic, for which throughput guidance 452 information is required, passes through a Radio Analytics application 453 which resides in a Mobile-edge Computing (MEC) server (see 454 [MEC_White_Paper]). This Radio Analytics application acts as the 455 Throughput Guidance Provider and sends throughput guidance 456 information for a TCP connection using the Options field in the TCP 457 header (according to the message specification provided in section 458 2). The TCP server MAY use this information to assist TCP congestion 459 control decisions as described above. The information MAY also be 460 used to select the application level coding so that it matches the 461 estimated capacity at the radio downlink for that TCP connection. 463 All of these improvements aim to enhance the quality of experience of 464 the end user by reducing the time-to-start of the content as well as 465 video stall occurrences. 467 3.1. Test Results 469 Nokia Networks and Google tested the video delivery optimization use 470 case in a live production LTE network. Google server was placed 471 close to the packet core network of LTE (SGi-interface of LTE). 472 Different network load scenarios were taken into consideration. TCP 473 CUBIC was used in these tests [MTG_ICCRG]. 475 Field trial performance results 477 +-------------------+-----------------------+-----------------------+ 478 | Performance | Difference of | Diff of 99th | 479 | metric | Averages (%) | percentiles | 480 +-------------------+-----------------------+-----------------------+ 481 | Time to play | -8.0% | -12% | 482 | Number of formats | +4.1% | +29.9% | 483 | Client bandwidth | +0.7% | +8.0% | 484 | Ave Video | +6.2% | +5.6% | 485 | resolution | | | 486 | Re-buffer time | -19.7% | -5.1% | 487 +-------------------+-----------------------+-----------------------+ 489 Table 1: Performance Data 491 These user experience improvements results into better video play and 492 are likely to offer longer battery life. 494 Table 3 summarizes the results from a field trial in the 3G network 495 of a Tier 1 mobile network operator in the Americas. As in the 496 previous case, the Google servers were located close to the packet 497 core network while the network elements from Vasona Networks 498 generated the Throughput Guidance messages. 500 It is interesting to note that the improvements that Throughput 501 Guidance provides are qualitatively different in LTE and 3G networks. 502 LTE networks generally have capacities that cannot be fully utilized 503 by CUBIC;s initial sending rate. On the other hand, Throughput 504 Guidance tends to be more conservative in 3G networks leading to 505 higher time to play. Video re-buffering is smaller in both cases. 507 3G field trial preformance results 509 +-------------------+-----------------------+-----------------------+ 510 | Performance | Difference of | Diff of 99th | 511 | metric | Averages (%) | percentiles | 512 +-------------------+-----------------------+-----------------------+ 513 | Time to play | +0.8% | +4.6% | 514 | Number of formats | -1.2% | +0.0% | 515 | Client bandwidth | +2.5% | -0.5% | 516 | Ave Video | +0.5% | -1.9% | 517 | resolution | | | 518 | Re-buffer time | -13.9% | -10.9% | 519 +-------------------+-----------------------+-----------------------+ 521 Table 2: Performance Data from 3G field trial 523 4. Manageability considerations 525 The application in the RAN SHOULD be configured with a list of 526 destinations to which throughput guidance should be provided. The 527 application in RAN will supply mobile throughput guidance information 528 to more than one TCP server simultaneously based on the list of 529 destinations. 531 In addition, it SHOULD be possible to configure the frequency (in 532 milliseconds) at which throughput guidance needs to be signaled as 533 well as the required security level and parameters for the encryption 534 and the authentication if supported. 536 5. Security considerations 538 Throughput guidance SHOULD be provided in a secure way. The 539 information can be provided as plain text in a secure and closed 540 network (e.g. inside operator network). In other cases, the 541 information should be authenticated (between the Throughput Guidance 542 Provider and the TCP server). 544 Section 2 described how the TCP Header information is protected. An 545 out-of-band mechanism is currently used to agree upon the set of keys 546 used to authenticate the messages exchanged between the endpoint and 547 the network element that generates the throughput guidance headers. 548 For example, service providers/OTTs can provide a portal that network 549 providers can use to configure the keys they use to encrypt/sign the 550 throughput guidance information. Then, a service behind the portal 551 ensures that the keys are distributed to the servers that need them. 553 As stated in [Req_Arch_MTG_Exposure], the policy configuration of the 554 Throughput Guidance Provider and the server endpoint, as well as the 555 key management are beyond the scope of this protocol definition. The 556 protocol assumes that a trustful relationship has been formed between 557 the Throughput Guidance Provider and the TCP server and that the 558 required security level is already configured by the operator and 559 agreed between the entities ( i.e. authentication, encryption or 560 both). 562 The identity of the Mobile Throughput Guidance provider that injects 563 the throughput guidance header must be explicitly known to the 564 endpoint receiving the information. Omitting such information would 565 enable malicious third parties to inject erroneous information. 567 Fortunately, the issue of malicious disinformation can be easily 568 addressed using well known techniques. First, the network entity 569 responsible for injecting the throughput guidance header can include 570 a cryptographically secure message authentication code. In this way 571 the transport endpoint that receives the throughput guidance header 572 can check that the information was sent by a legitimate entity and 573 that the information has not been tampered with. 575 Furthermore, the throughput guidance information should be treated 576 only as an estimate to the congestion control algorithm running at 577 the transport endpoint. The endpoint that receives this information 578 should not assume that it is always correct and accurate. 579 Specifically, endpoints should check the validity of the information 580 received and if they find it erroneous they should discard it and 581 possibly take other corrective actions (e.g., discard all future 582 throughput guidance information from a particular IP prefix). 583 Endpoints MUST process throughput guidance information only from TCP 584 segments that would be otherwise be accepted as part of the standard 585 TCP input process. For example, the receiver should ignore 586 throughput guidance information included in TCP ACKs whose 587 acknowledgement sequence numbers fall outside the range of valid 588 sequence numbers. 590 6. IANA considerations 592 In the current version of the document and for field tests, the 593 experimental value 253 is used for the "Throughput Guidance" TCP 594 option kind. ExpID SHOULD be set to 0x6006 (16 bits) 596 7. Acknowledgements 598 8. References 599 8.1. Normative References 601 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 602 RFC 793, DOI 10.17487/RFC0793, September 1981, 603 . 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 611 RFC 6994, DOI 10.17487/RFC6994, August 2013, 612 . 614 8.2. Informative References 616 [I-D.narten-iana-considerations-rfc2434bis] 617 Narten, T. and H. Alvestrand, "Guidelines for Writing an 618 IANA Considerations Section in RFCs", draft-narten-iana- 619 considerations-rfc2434bis-09 (work in progress), March 620 2008. 622 [MEC_White_Paper] 623 ETSI, "Mobile-Edge Computing - Introductory Technical 624 White Paper", 2014. 626 [MTG_ICCRG] 627 Szilagyi, P., and Terzis, A., "Mobile Content Delivery 628 Optimization based on Throughput Guidance", Presentation 629 at ICCRG meeting IETF93 (work in progress), July 2015. 631 [Req_Arch_MTG_Exposure] 632 Jain, A., , Terzis, A., , Sprecher, N., , Arunachalam, S., 633 , Smith, K., , and G. Klas, "Requirements and reference 634 architecture for Mobile Throughput Guidance Exposure", 635 draft-sprecher-mobile-tg-exposure-req-arch-01.txt (work in 636 progress), February 2015. 638 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 639 DOI 10.17487/RFC2629, June 1999, 640 . 642 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 643 of Explicit Congestion Notification (ECN) to IP", 644 RFC 3168, DOI 10.17487/RFC3168, September 2001, 645 . 647 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 648 Text on Security Considerations", BCP 72, RFC 3552, 649 DOI 10.17487/RFC3552, July 2003, 650 . 652 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 653 DOI 10.17487/RFC4413, March 2006, 654 . 656 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 657 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 658 June 2010, . 660 [tcp-ao-encrypt] 661 Touch, J., , "A TCP Authentication Option Extension for 662 Payload Encryption", draft-touch-tcp-ao-encrypt- 663 02.txt (work in progress), November 2014. 665 [tcp-edo] Touch, J., and Eddy, W., "TCP Extended Data Offset 666 Option", draft-ietf-tcpm-tcp-edo-01.txt (work in 667 progress), October 2013. 669 Appendix A. 671 Authors' Addresses 673 Ankur Jain 674 Google 675 1600 Amphitheatre Parkway 676 Mountain View, CA 94043 677 US 679 Phone: +1-925-526-5879 680 Email: jankur@google.com 682 Andreas Terzis 683 Google 684 1600 Amphitheatre Parkway 685 Mountain View, CA 94043 686 US 688 Phone: +1-650-214-5270 689 Email: aterzis@google.com 690 Hannu Flinck 691 Nokia Networks 692 Karaportti 13 693 Espoo 694 FI 696 Phone: +358504839522 697 Email: hannu.flinck@nokia-bell-labs.com 699 Nurit Sprecher 700 Nokia Networks 701 Hod HaSharon 702 IL 704 Phone: +97297751229 705 Email: nurit.sprecher@nokia.com 707 Swaminathan Arunachalam 708 Nokia Networks 709 Irving, TX 710 US 712 Phone: +19723303204 713 Email: swaminathan.arunachalam@nokia.com 715 Kevin Smith 716 Vodafone 717 One Kingdom Street, Paddington Central 718 London W2 6BY 719 UK 721 Phone: +19723303204 722 Email: kevin.smith@vodafone.com 724 Vijay Devarapalli 725 Vasona Networks 727 Email: vijay@vasonanetworks.com 729 Roni Bar Yanai 730 Vasona Networks 732 Email: rbaryanai@vasonanetworks.com