idnits 2.17.1 draft-flinck-mobile-throughput-guidance-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 : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 29 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 543 has weird spacing: '...y Index and t...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The plaintext contains type-value pair elements of the variable length data. The plaintext is divided into blocks of 16 bytes. A block of plain text MUST not exceed 16 bytes in a single run. Encryption takes a key (16 bytes), an IV or Nonce (16 bytes), the plain-text (at most 16 bytes) and produces a cipher text of 16 bytes. Note: multiple keys, at most 256, may be available (can be exchanged via an out-of-band key management mechanism such as Diffie-Hellman key exchange; this is out of scope of this document) for encryption key index. The keys MUST be different from those used for authentication. -- The document date (March 9, 2015) is 3328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3168' is mentioned on line 233, but not defined == Missing Reference: 'RFC5925' is mentioned on line 318, but not defined == Missing Reference: 'RFC793' is mentioned on line 326, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 777, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC4413' is defined on line 794, 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: 3 errors (**), 0 flaws (~~), 10 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 10, 2015 H. Flinck 6 N. Sprecher 7 S. Arunachalam 8 Nokia Networks 9 K. Smith 10 Vodafone 11 March 9, 2015 13 Mobile Throughput Guidance Inband Signaling Protocol 14 draft-flinck-mobile-throughput-guidance-01.txt 16 Abstract 18 The bandwidth available for end user devices in cellular networks can 19 vary by an order of magnitude over a few seconds due to changes in 20 the underlying radio channel conditions, as device mobility and 21 changes in system load as other devices enter and leave the network. 22 Furthermore, packets losses are not always signs of congestion. The 23 Transmission Control Protocol (TCP) can have difficulties adapting to 24 these rapidly varying conditions leading to inefficient use of a 25 cellular network's resources and degraded application performance. 26 Problem statement, requirements and the architecture for a solution 27 is documented in [Req_Arch_MTG_Exposure] 29 This document proposes a mechanism and protocol elements that allow 30 the cellular network to provide near real-time information on 31 capacity available to the TCP server. This "Throughput Guidance" 32 (TG) information would indicate the throughput estimated to be 33 available at the radio downlink interface (between the Radio Access 34 Network (RAN) and the mobile device (UE)). TCP server can use this 35 TG information to ensure high network utilization and high service 36 delivery performance. The document describes the applicability of 37 the proposed mechanism for video delivery over cellular networks; it 38 also presents test results from live operator's environment. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 10, 2015. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . 3 76 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 78 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.5. Assumptions and Considerations for the Solution . . . . . 4 80 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 2.1. Common Kind-Length-Value header . . . . . . . . . . . . . 8 82 2.2. Plain text mode Throughput Guidance Options . . . . . . . 10 83 2.3. Encrypted mode . . . . . . . . . . . . . . . . . . . . . 11 84 2.4. Nonce (Initialization Vector) . . . . . . . . . . . . . 13 85 2.5. Authentication . . . . . . . . . . . . . . . . . . . . . 14 86 3. Applicability to Video Delivery Optimization . . . . . . . . 15 87 3.1. Test Results . . . . . . . . . . . . . . . . . . . . . . 15 88 4. Manageability considerations . . . . . . . . . . . . . . . . 16 89 5. Security considerations . . . . . . . . . . . . . . . . . . . 16 90 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 8.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 The problem statement related to the behavior of the TCP in cellular 101 networks is provdied 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: Peterm Szilagyi/Nokia, Csaba Vulkan/Nokia, Ram Gobal/ 118 Nokia, Guenter Klas/Vodaphone and Peter Cosimini/Vodaphone. 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 in the RAN that signals to the TCP server the 152 information on the (near-real time) throughput estimated to be 153 available at the radio downlink interface 155 1.5. Assumptions and Considerations for the Solution 157 This document specifies a solution protocol that is compliant with 158 the requirements and architecture specified in 159 [Req_Arch_MTG_Exposure]. The protocol is used by the cellular 160 network to provide throughput guidance information to the TCP server; 161 this information indicates the throughput estimated to be available 162 at the radio downlink interface for the TCP connection. The protocol 163 allows the information to be provided in near real time in situations 164 where the network conditions are changing frequently or the user is 165 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, e.g 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. The proposed scheme is similar to existing 232 mechanisms such as ECN, where an ECN- aware router sets a mark in the 233 IP header in order to signal impending congestion (see [RFC3168]). 234 Note, however, that the proposed scheme provides explicit 235 information, (termed "Throughput Guidance") about the estimated 236 throughput available for the TCP connection at the radio link between 237 the RAN and the UE. 239 Note that once standardized and implemented, TCP Extended Data option 240 (TCP-EDO) can be used to carry the throughput guidance information as 241 specified in [tcp-edo] and simplify the use of the TCP Option fields 242 by extending the space available for TCP options. Currently the TCP- 243 EDO is still work in progress and not available in production. 244 Therefore, the use of TCP-EDO to carry throughput guidance is left 245 for the later drafts. 247 2. Protocol 249 This section describes the protocol mechanism and the information 250 element that needs to be communicated from the RAN to the TCP remote 251 endpoint. We describe the protocol mechanism and message format for 252 throughput guidance. The protocol mechanism is defined in an 253 extensible way to allow additional information to be specified and 254 communicated. The protocol specification is based on the existing 255 experiments and running code. It is recommended to insert the 256 throughput guidance information to the TCP segments that flow from 257 client to server (see reasoning in "Assumptions and Considerations" 258 section). Most of the time, TCP segments are ACK packets from a 259 client to the server and hence packets are unlikely to be fragmented. 260 However, the described protocol solution can deal with fragmentation. 262 The Mobile Throughput Guidance Signaling message conveys information 263 on the throughput estimated to be available at the down link path for 264 a given TCP connection. The information is sent to the uplink end- 265 point of the connection (i.e, the TCP server). The TCP server MAY 266 use this information to adapt TCP behavior and to adjust application- 267 level behavior to the link conditions as defined in 268 [Req_Arch_MTG_Exposure]. 270 A good example is a content optimizer or a cache that can adapt the 271 application-level coding to match the indicated downlink radio 272 conditions. As radio link conditions may change rapidly, this 273 guidance information is best carried in-band using TCP options 274 headers rather than through an out-of-band protocol. 276 Using the TCP options to carry throughput guidance associates the 277 guidance information with an ongoing TCP connection and explicitly 278 avoids separate session identification information. The proposed 279 mechanism neither impacts the TCP state machine nor the congestion 280 control algorithms of the TCP protocol. 282 The Options field enables information elements to be inserted into 283 each packet with a 40-byte overall limit; this needs to be shared 284 with the standardized and widely-used option elements, such as the 285 TimeStamp and SACK. (Use of TCP-EDO will lift this constraint once 286 available and deployed). The TCP Options field uses a Kind-Length- 287 Value structure that enables TCP implementations to interpret or 288 ignore information elements in the Options field based on the Kind. 290 In this draft, we define a Kind-Length-Value structure for encoding 291 information about the estimated capacity of a radio access link 292 between the RAN and the UE which is traversed by a TCP connection. 293 The intention is to define a generic container to convey in-band 294 information within the limited TCP Option space with optional 295 authentication and/or encryption capabilities. Throughput guidance 296 is the conveyed information in this document. Additional information 297 can be specified in future. 299 The Throughput Guidance Provider functional element inserts Mobile 300 Throughput Guidance TCP options only if there is enough space in the 301 TCP header. The Throughput Guidance Provider resides on top of a 302 radio network element see [Req_Arch_MTG_Exposure]). 304 Confidential information must be delivered in a secure way. The 305 information can be provided as plain text in a secure and closed 306 network. In other cases, the information should be authenticated and 307 encrypted at the TCP-header level (between the Throughput Guidance 308 Provider and the TCP server). An acceptable level of authentication 309 and encryption (according to best common practices) may require more 310 data than fits into a single TCP header (maximum of 40 bytes if no 311 other options are present). As described below, fragmenting 312 information across multiple packets will be used is such a case. 314 Two transfer modes are defined to deal with data confidentiality in 315 this document; namely, plain-text mode and authenticated encryption 316 mode. A third mode, authentication-only mode, is equally feasible. 317 A third mode, authentication-only mode, is equally feasible and may 318 use TCP Authentication Option (TCP-AO) (see RFC 5935 [RFC5925]). We 319 will describe the authentication-only mode in detail in future 320 version of this draft. Both modes share a common Kind-Length-Value 321 "option header" structure with a flag field separating the two cases. 323 2.1. Common Kind-Length-Value header 325 Mobile Throughput Guidance Signaling uses the common TCP options 326 structure as in [RFC793] with experimental identifier as defined in 327 [RFC6994]. To make Mobile Throughput Guidance Signaling extendible 328 to different use cases a common Kind-Length-Value structure is 329 defined below. 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |Kind | Length | ExID |Flags| variable length data | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 1 337 Kind: 339 Code point 253 for Experimental Opition for 16-bit ExID [RFC6994]. 340 The size of this field is 1 byte. 342 Length: 344 A 1 byte field, length of the option in bytes as defined in 345 RFC793. 347 ExID 349 Two bytes Experimental Identifier according to [RFC6994]. Code 350 point 0x6006. 352 Flags: 354 One byte of MTG protocol flag field as defined below. 356 0 1 2 3 4 5 6 7 357 +-+-+-+-+-+-+-+-+ 358 | Seq |Frag |P|T| 359 +-+-+-+-+-+-+-+-+ 361 Flag field of common Kind-Length-Value header 363 Figure 2 365 Seq: 367 Three-bit sequence number that maintains context across different 368 packet types as defined by P- and T-bits below. The scope of the 369 sequence number is to protect against packet reordering, not to 370 provide a globally unique identifier or sequence number. The use 371 of these bits are reserved for possible transfer mode extensions. 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 Variable length data: 392 The variable length content (i.e. option data) in 393 format. The content depends of the transfer mode as defined in 394 the following sections of this document. If the option data is 395 fragmented across multiple headers the first fragment (marked with 396 Frag=001 in the Flags-field) contains "Total Length of Data"-field 397 that is the length of the variable data of MTG in all the 398 fragments. Total Length of Data field is followed the content in 399 -format. 401 As an example for the use of the Flags-field, consider a cipher text 402 of a single block. For it the T-bit is set to one, P-bit is set to 403 zero, Fragment and Seq-fields are zero in the Flags-field. In case 404 the cipher text option cannot fit into a single TCP packet option, 405 the cipher text is fragmented across multiple TCP headers. The first 406 fragment has value Frag= 001, and the value is incremented for each 407 subsequent fragment. The first fragment contains the "Total Length 408 of Data"-field indicating the total length of the data to be 409 fragmented. Last fragment is marked with all Frag-bits set to 1 410 (Frag= 111 for the last fragment). Therefore, the maximum number of 411 fragments is seven. Details follow in the next sections. 413 2.2. Plain text mode Throughput Guidance Options 415 The plain text mode can be used in secure and closed networks or with 416 information that has no confidentiality requirement. The plain text 417 mode is made of one or more type-value pairs. The type determines 418 the length of the following value. 420 Table of Type Value pairs of Throughput Guidance option data 422 +---------------------+------+----------+------------------+ 423 | Name | Type | Length | Unit of the type | 424 +---------------------+------+----------+------------------+ 425 | Throughput Guidance | 1 | 2 bytes | Mbits/s | 426 +---------------------+------+----------+------------------+ 428 Table 1: MTG type-vale pairs 430 g The Type 1 element carries the actual throughput estimate in the 431 16-bit value field The throughput value is encoded using a fixed- 432 point number representation. The 12 most significant bits are used 433 for the integer value while the bottom 4 bits correspond to the 434 decimal portion of the throughput value. Throughput is expressed in 435 Megabits per second. 437 The type-value pair elements are laid out consecutively in the 438 header. At the end padding (i.e., the NO-OP TCP Option header with 439 kind equal to 1, or the End of Option List TCP Option header with 440 kind equal to 0) may be required to align the header size to the 441 multiple of 4 bytes (required by the TCP standard). All bits in the 442 Flag field are set to zero. 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |Kind | Length |ExID|Flags |Type1|Value-1| Type2|Value-2| ... | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Kind, Length, ExID remains same as described in section 2.1. 448 Options data constitutes the Flags and the variable length data. 449 Flags: P- and T-bits set to zero 451 Layout of plain text option data in the TCP header options space. 453 Figure 3 455 2.3. Encrypted mode 457 Encryption requires authentication for integrity protection, as it is 458 insecure to use encryption without it. Thus, the encrypted mode 459 contains authentication as well. Encryption and authentication must 460 use different keys. The following diagram shows the encryption 461 process. 463 +-+-+-+-+ +-+-+-+-+-+ 464 +-+-+-+-+-+ | key1 | |IV(Nonce)| 465 |key index| --> +-+-+-+-+ +-+-+-+-+-+ 466 +-+-+-+-+-+ | key 2 | | 467 +-+-+-+-+ key +-+-+-V-+-+-+-+ 468 ... ----> | AES 128-CNT| 469 +-+-+-+-+ +-+-+-+-+-+-+-+ 470 | key n | | 471 +-+-+-+-+ +<------ Plain text 472 | 473 +-+-+-V-+-+-+-+ 474 | Cipher text | 475 +-+-+-+-+-+-+-+ 477 Encryption method 479 Figure 4 481 The encryption uses Advanced Encryption Standard (AES), 128 bits (16 482 bytes) block size, 128 bits (16 bytes) key size, Counter (CTR) block 483 cipher mode. Integrity protection with CTR mode is MUST; this is 484 provided via HMAC based message authentication (see Authentication 485 section below). 487 The plaintext contains type-value pair elements of the variable 488 length data. The plaintext is divided into blocks of 16 bytes. A 489 block of plain text MUST not exceed 16 bytes in a single run. 490 Encryption takes a key (16 bytes), an IV or Nonce (16 bytes), the 491 plain-text (at most 16 bytes) and produces a cipher text of 16 bytes. 492 Note: multiple keys, at most 256, may be available (can be exchanged 493 via an out-of-band key management mechanism such as Diffie-Hellman 494 key exchange; this is out of scope of this document) for encryption 495 key index. The keys MUST be different from those used for 496 authentication. 498 The Nonce is 16 bytes. A unique Nonce is generated for each 499 encrypted block. The same Initialization Vector, IV or Nonce MUST 500 NOT be used with the same encryption key more than once. This is to 501 be enforced by the Throughput Guidance Provider; otherwise security 502 scheme will be broken. 504 The resulting cipher text is in blocks of 16 bytes. The cipher text 505 blocks are packed into the option space together with the used Key 506 Index in a following way if they fit into single option space of a 507 single TCP header. 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |Kind | Length |ExID| Flags | Key Index |first block of 16 bytes | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Kind, Length, ExID remains same as described in section 2.1. 514 Options data constitutes the Flags and the variable length data. 515 Flags: Type of cipher text T-bit set to 1, only one block Frag= 000. 516 Key Index is the index used in encryption 518 Cipher text layout in the TCP options without fragmentation 520 Figure 5 522 The flag field of the common option header indicates that the content 523 is cipher text by having the T bit set to one. Since the ciphered 524 block is not fragmented the Frag-bits of the flag field are set to 525 zero (Frag= 000). (Use of Seq bits is left for later submissions). 526 If there is not enough space to accommodate the 16 bytes in the 527 option data, the data is fragmented. 529 If there are multiple cipher text blocks of 16 bytes, the flag field 530 shows the type of the option being cipher text with the T-bit set to 531 one, and by Frag-field showing the fragment number starting from 001 532 and incremented by one for each subsequent fragment of a packet of 533 the same type. For the last fragment, the Frag-field is always 534 binary 111 to indicate the last fragment. 536 First fragment: 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |Kind |Length|ExID|Flags| Total Length|KeyIndex|1. block |fragmented block | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Kind, Length, ExID remains same as described in section 2.1 543 Options data constitutes the Flags, Total Length, Key Index and the variable length data. 544 Flags: Type of cipher text T-bit = 1, Frag field = 001 first fragment 545 Total Length: total number of bytes of option data to be fragmented 546 Key Index is the index used in encryption 548 Second fragment if the last one: 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |Kind | Length | ExID |Flags| Key Index | Rest of the fragmented block | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Kind, Length, ExID remains same as described in section 2.1 555 Options data constitutes the Flags, Key Index and the variable length data. 556 Flags: Type of cipher text T-bit = 1, Frag field = 111 last fragment, otherwise 010. 557 Total Length: total number of bytes in the fragments 558 Key Index is the index used in encryption 560 Cipher text layout extending to two consecutive headers 562 Figure 6 564 2.4. Nonce (Initialization Vector) 566 The 16 byte Nonce (or IV) is transmitted along with the cipher text 567 to protect against de-synchronization between the encryption- 568 decryption points. 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 |Kind | Length | ExID |Flags| Key Index | Nonce (IV) 16 bytes | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Kind, Length, ExID remains same as described in section 2.1 575 Options data constitutes the Flags and the variable length data. 576 Flags: Type of IV/Nonce P-bit set to 1, only one block Frag= 000 577 Key Index is the index used in encryption 579 Nonce (IV) in a single header 581 Figure 7 583 If the Nonce (IV) doesn't fit into the remaining free bytes of the 584 option field it needs to be fragmented using the Frag-field in the 585 same way as cipher text layout is extending across two or more 586 consecutive TCP headers but with the option type field set to 587 indicate Nonce/IV by P-bit set to 1. 589 2.5. Authentication 591 The authentication covers the cipher text, the Nonce (IV) and 592 includes additional TCP protocol header fields to protect against 593 replay attacks. The authentication uses HMAC codes (e.g. HMAC- 594 SHA2-224), 128 bits (16 bytes) key size, 224 bits (28 bytes) digest 595 size. Multiple keys (at most 256) for authentication with the same 596 information receiver can be used. The keys MUST be different from 597 those used for encryption. Truncation is possible but at least 160 598 bits (20 bytes) must be used from the digest to meet the typical 599 security level of mobile networks. 601 Authentication takes a key, the input (arbitrary length) and produces 602 a 28 byte long digest, which is truncated to 20 bytes (keeping the 603 most significant bytes). The HMAC algorithm and truncation can be 604 negotiated via key management (out of scope of this document). 606 The authentication covers the TCP sequence number, ACK number, and 607 TimeStamp (TSval, TSecr not the possible 2 bytes of padding) fields 608 of the TCP header as well as the Common Kind-Length-ExID-header with 609 its data in all cipher text option and IV/Nonce option packets. (The 610 Authentication type options itself cannot be covered by the 611 authentication.) 613 The order in which the fields are included into the message 614 authentication code is the following. From the TCP header: TCP Seq, 615 ACK, TSval, TSecr. Followed by the following fields from the 616 ciphered text: Kind, Length, ExID, Flags, Key Index, cipher text, and 617 from the IV/Nonce type of option packets TCP Seq, ACK, TSval, TSecr 618 (note cipher text and IV/Nonce type of options may be in different 619 TCP packets) followed by Kind, Length, ExID, Flags, Key Index, Nonce/ 620 IV. 622 In case the option packets used as input to the HMAC are fragmented 623 into multiple TCP headers, they are processed so that headers with 624 cipher text option are processed first, followed by IV/Nonce option 625 packets. 627 The options containing the result of the HMAC are marked by setting 628 both P- and T-bits of the flag-field to one. Key Index is set to 629 point to the used authentication key, followed by the resulting 630 authentication code. If the option doesn't fit into the free option 631 space in the TCP header, it is fragmented across multiple TCP headers 632 in the same way as the cipher text options. 634 3. Applicability to Video Delivery Optimization 636 The applicability of the protocol specified in this document to 637 mobile video delivery optimization has been evaluated and tested in 638 different network load scenarios. 640 In this use case, TCP traffic, for which throughput guidance 641 information is required, passes through a Radio Analytics application 642 which resides in a Mobile-edge Computing (MEC) server (see 643 [MEC_White_Paper]). This Radio Analytics application acts as the 644 Throughput Guidance Provider and sends throughput guidance 645 information for a TCP connection using the Options field in the TCP 646 header (according to the message specification provided in section 647 2). The TCP server MAY use this information to assist TCP congestion 648 control decisions as described above. The information MAY also be 649 used to select the application level coding so that it matches the 650 estimated capacity at the radio downlink for that TCP connection. 652 All of these improvements aim to enhance the quality of experience of 653 the end user by reducing the time-to-start of the content as well as 654 video stall occurrences. 656 3.1. Test Results 658 Nokia Networks and Google tested the video delivery optimization use 659 case in a live production environmentDifferent network load scenarios 660 were taken into consideration. TCP Cubic was used in these tests and 661 the TG information was used by the TCP based video server to adjust 662 TCP congestion window only. The results below are based on data for 663 whole 2 days (23rd and 25th Feb 2015). 665 All network level metrics showed an average improvement of 30-60%, as 666 detailed below: 668 o Reduction of end-to-end TCP RTT by 55-70% 670 o TCP retransmissions reduced by 30-45% 672 o Mean Client Throughput improved by 20-35% 674 o TCP packet loss reduced by 35-50% 676 The application-level metrics show an average improvement as detailed 677 below: 679 o Click-to-play time reduced by 5-20% 681 o Average video resolution improvement by 5- 20% 683 o Reduction in the number of format changes by 10 - 25% 685 These user experience improvements results in faster video time to 686 play and are likely to result in longer battery life. 688 4. Manageability considerations 690 The application in the RAN SHOULD be configured with a list of 691 destinations to which throughput guidance should be provided. The 692 application in RAN will supply mobile throughput guidance information 693 to more than one TCP server simultaneously based on the list of 694 destinations. 696 In addition, it SHOULD be possible to configure the frequency (in 697 milliseconds) at which throughput guidance needs to be signaled as 698 well as the required security level and parameters for the encryption 699 and the authentication if supported. 701 5. Security considerations 703 Throughput guidance is considered confidential information and it 704 SHOULD be provided in a secure way. The information can be provided 705 as plain text in a secure and closed network (e.g. inside operator 706 network). In other cases, the information should be authenticated 707 and encrypted at the TCP-header level (between the Throughput 708 Guidance Provider and the TCP server). 710 Section 2 described how the TCP Header information can be signed and 711 encrypted for security purposes. An out-of-band mechanism is 712 currently used to agree upon the set of keys used to encrypt and 713 authenticate the messages exchanged between the endpoint and the 714 network element that generates the throughput guidance headers. 716 As stated in [Req_Arch_MTG_Exposure], the policy configuration of the 717 Throughput Guidance Provider and the server endpoint, as well as the 718 key management and the encryption algorithm are beyond the scope of 719 this protocol definition. The protocol assumes that a trustful 720 relationship has been formed between the Throughput Guidance Provider 721 and the TCP server and that the required security level is already 722 configured by the operator and agreed between the entities ( i.e. 723 authentication, encryption or both). 725 The identity of the Mobile Throughput Guidance provider that injects 726 the throughput guidance header must be explicitly known to the 727 endpoint receiving the information. Omitting such information would 728 enable malicious third parties to inject erroneous information. 730 Fortunately, the issue of malicious disinformation can be easily 731 addressed using well known techniques. First, the network entity 732 responsible for injecting the throughput guidance header can encrypt 733 the header and include a cryptographically secure message 734 authentication code. In this way the transport endpoint that 735 receives the throughput guidance header can check that the 736 information was sent by a legitimate entity and that the information 737 has not been tampered with. 739 Furthermore, the throughput guidance information should be treated 740 only as an estimate to the congestion control algorithm running at 741 the transport endpoint. The endpoint that receives this information 742 should not assume that it is always correct and accurate. 743 Specifically, endpoints should check the validity of the information 744 received and if they find it erroneous they should discard it and 745 possibly take other corrective actions (e.g., discard all future 746 throughput guidance information from a particular IP prefix). 748 The impact of TCP Authentication Option (TCP-AO) with encrypted TCP 749 segment payload [tcp-ao-encrypt] implies that the Throughput Guidance 750 Provider functional element acts as a full back to back TCP proxy. 751 This case is left for later stages as the work [tcp-ao-encrypt] is 752 still at draft stage. 754 6. IANA considerations 756 In the current version of the document and for field tests, the 757 experimental value 253 is used for the "Throughput Guidance" TCP 758 option kind. ExpID SHOULD be set to 0x6006 (16 bits) 760 7. Acknowledgements 762 8. References 764 8.1. Normative References 766 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 767 793, September 1981. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997. 772 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 773 6994, August 2013. 775 8.2. Informative References 777 [I-D.narten-iana-considerations-rfc2434bis] 778 Narten, T. and H. Alvestrand, "Guidelines for Writing an 779 IANA Considerations Section in RFCs", draft-narten-iana- 780 considerations-rfc2434bis-09 (work in progress), March 781 2008. 783 [MEC_White_Paper] 784 ETSI, "Mobile-Edge Computing - Introductory Technical 785 White Paper", 2014. 787 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 788 June 1999. 790 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 791 Text on Security Considerations", BCP 72, RFC 3552, July 792 2003. 794 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 795 March 2006. 797 [Req_Arch_MTG_Exposure] 798 Jain, A., Terzis, A., Sprecher, N., Arunachalam, S., 799 Smith, K., and G. Klas, "Requirements and reference 800 architecture for Mobile Throughput Guidance Exposure", 801 draft-sprecher-mobile-tg-exposure-req-arch-01.txt (work in 802 progress), February 2015. 804 [tcp-ao-encrypt] 805 Touch, J., , "A TCP Authentication Option Extension for 806 Payload Encryption", draft-touch-tcp-ao-encrypt-02.txt 807 (work in progress), November 2014. 809 [tcp-edo] Touch, J., and Eddy, W., "TCP Extended Data Offset 810 Option", draft-ietf-tcpm-tcp-edo-01.txt (work in 811 progress), October 2013. 813 Appendix A. 815 Authors' Addresses 817 Ankur Jain 818 Google 819 1600 Amphitheatre Parkway 820 Mountain View, CA 94043 821 US 823 Phone: +1-925-526-5879 824 Email: jankur@google.com 826 Andreas Terzis 827 Google 828 1600 Amphitheatre Parkway 829 Mountain View, CA 94043 830 US 832 Phone: +1-650-214-5270 833 Email: aterzis@google.com 835 Hannu Flinck 836 Nokia Networks 837 Helsinki 838 FI 840 Phone: +358504839522 841 Email: hannu.flinck@nokia.com 843 Nurit Sprecher 844 Nokia Networks 845 Hod HaSharon 846 IL 848 Phone: +97297751229 849 Email: nurit.sprecher@nsn.com 850 Swaminathan Arunachalam 851 Nokia Networks 852 Irving, FUS 853 US 855 Phone: +19723303204 856 Email: swaminathan.arunachalam@nsn.com 858 Kevin Smith 859 Vodafone 860 One Kingdom Street, Paddington Central 861 London W2 6BY 862 UK 864 Email: kguenter.klas@vodafone.com