idnits 2.17.1 draft-flinck-mobile-throughput-guidance-03.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 24 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 545 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 (September 7, 2015) is 3154 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 778, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'RFC4413' is defined on line 814, 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 (~~), 7 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 10, 2016 H. Flinck 6 N. Sprecher 7 S. Arunachalam 8 Nokia Networks 9 K. Smith 10 Vodafone 11 September 7, 2015 13 Mobile Throughput Guidance Inband Signaling Protocol 14 draft-flinck-mobile-throughput-guidance-03.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 March 10, 2016. 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: 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 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 [RFC5935]). 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 [RFC0793] 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. To make Mobile Throughput Guidance Signaling 330 extendible to different use cases a common Kind-Length-Value header 331 is defined below. 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |Kind | Length | ExID |Flags| variable length data | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 1 339 Kind: 341 Code point 253 for Experimental Opition for 16-bit ExID [RFC6994]. 342 The size of this field is 1 byte. 344 Length: 346 A 1 byte field, length of the option in bytes as defined in 347 RFC793. 349 ExID: 351 Two bytes Experimental Identifier according to [RFC6994]. Code 352 point 0x6006. 354 Flags: 356 One byte of MTG protocol flag field as defined below. 358 0 1 2 3 4 5 6 7 359 +-+-+-+-+-+-+-+-+ 360 | Seq |Frag |P|T| 361 +-+-+-+-+-+-+-+-+ 363 Flag field of common Kind-Lenght-Value header 365 Figure 2 367 Seq: 369 Three-bit sequence number that maintains context across different 370 packet types as defined by P- and T-bits below. The scope of the 371 sequence number is to protect against packet reordering, not to 372 provide a globally unique identifier or sequence number. The use 373 of these bits are reserved for possible transfer mode extensions. 375 Frag: 377 Three bits that provide information about how to reassemble 378 information if fragmented into multiple packets. If no 379 fragmentation across multiple TCP packet headers is needed, these 380 bits are set to zero. Otherwise, Frag is a counter starting from 381 1 and incremented by 1 for each subsequent packet of the same type 382 (see P- and T-bits below). For the last fragment, the Fragment is 383 always 7 (binary 111) to indicate that the information is 384 complete. 386 P and T bits: 388 These two bits encode the packet type: Plaintext (P=0, T= 0), 389 Cipher text (P=0, T=1), Nonce (IV) (P=1, T=0) or Authentication 390 (P=1, T=1). For Plaintext, the Fragment bits are always zero. 392 Variable length data: 394 The variable length content (i.e. option data) in 395 format. The content depends of the transfer mode as defined in 396 the following sections of this document. If the option data is 397 fragmented across multiple headers the first fragment (marked with 398 Frag=001 in the Flags-field) contains "Total Length of Data"-field 399 that is the length of the variable data of MTG in all the 400 fragments. Total Length of Data field is followed the content in 401 -format 403 As an example for the use of the Flags-field, consider a cipher text 404 of a single block. For it the T-bit is set to one, P-bit is set to 405 zero, Fragment and Seq-fields are zero in the Flags-field. In case 406 the cipher text option cannot fit into a single TCP packet option, 407 the cipher text is fragmented across multiple TCP headers. The first 408 fragment has value Frag= 001, and the value is incremented for each 409 subsequent fragment. The first fragment contains the "Total Length 410 of Data"-field indicating the total length of the data to be 411 fragmented. Last fragment is marked with all Frag-bits set to 1 412 (Frag= 111 for the last fragment). Therefore, the maximum number of 413 fragments is seven. Details follow in the next sections. 415 2.2. Plain text mode Throughput Guidance Options 417 The plain text mode can be used in secure and closed networks or with 418 information that has no confidentiality requirement. The plain text 419 mode is made of one or more type-value pairs. The type determines 420 the length of the following value. 422 Table of Type Value pairs of Throughput Guidance option data 424 +---------------------+------+----------+------------------+ 425 | Name | Type | Length | Unit of the type | 426 +---------------------+------+----------+------------------+ 427 | Throughput Guidance | 1 | 2 bytes | Mbits/s | 428 +---------------------+------+----------+------------------+ 430 Table 1: MTG type-vale pairs 432 The Type 1 element carries the actual throughput estimate in the 433 16-bit value field The throughput value is encoded using a fixed- 434 point number representation. The 12 most significant bits are used 435 for the integer value while the bottom 4 bits correspond to the 436 decimal portion of the throughput value. Throughput is expressed in 437 Megabits per second. 439 The type-value pair elements are laid out consecutively in the 440 header. At the end padding (i.e., the NO-OP TCP Option header with 441 kind equal to 1, or the End of Option List TCP Option header with 442 kind equal to 0) may be required to align the header size to the 443 multiple of 4 bytes (required by the TCP standard). All bits in the 444 Flag field are set to zero. 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |Kind | Length |ExID|Flags |Type1|Value-1| Type2|Value-2| ... | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Kind, Length, ExID remains same as described in section 2.1. 450 Options data constitutes the Flags and the variable length data. 451 Flags: P- and T-bits set to zero 453 Layout of plain text option data in the TCP header options space. 455 Figure 3 457 2.3. Encrypted mode 459 Encryption requires authentication for integrity protection, as it is 460 insecure to use encryption without it. Thus, the encrypted mode 461 contains authentication as well. Encryption and authentication must 462 use different keys. The following diagram shows the encryption 463 process. 465 +-+-+-+-+ +-+-+-+-+-+ 466 +-+-+-+-+-+ | key1 | |IV(Nonce)| 467 |key index| --> +-+-+-+-+ +-+-+-+-+-+ 468 +-+-+-+-+-+ | key 2 | | 469 +-+-+-+-+ key +-+-+-V-+-+-+-+ 470 ... ----> | AES 128-CNT| 471 +-+-+-+-+ +-+-+-+-+-+-+-+ 472 | key n | | 473 +-+-+-+-+ +<------ Plain text 474 | 475 +-+-+-V-+-+-+-+ 476 | Cipher text | 477 +-+-+-+-+-+-+-+ 479 Encryption method 481 Figure 4 483 The encryption uses Advanced Encryption Standard (AES), 128 bits (16 484 bytes) block size, 128 bits (16 bytes) key size, Counter (CTR) block 485 cipher mode. Integrity protection with CTR mode is MUST; this is 486 provided via HMAC based message authentication (see Authentication 487 section below). 489 The plaintext contains type-value pair elements of the variable 490 length data. The plaintext is divided into blocks of 16 bytes. A 491 block of plain text MUST not exceed 16 bytes in a single run. 492 Encryption takes a key (16 bytes), an IV or Nonce (16 bytes), the 493 plain-text (at most 16 bytes) and produces a cipher text of 16 bytes. 494 Note: multiple keys, at most 256, may be available (can be exchanged 495 via an out-of-band key management mechanism such as Diffie-Hellman 496 key exchange; this is out of scope of this document) for encryption 497 key index. The keys MUST be different from those used for 498 authentication. 500 The Nonce is 16 bytes. A unique Nonce is generated for each 501 encrypted block. The same Initialization Vector, IV or Nonce MUST 502 NOT be used with the same encryption key more than once. This is to 503 be enforced by the Throughput Guidance Provider; otherwise security 504 scheme will be broken. 506 The resulting cipher text is in blocks of 16 bytes. The cipher text 507 blocks are packed into the option space together with the used Key 508 Index in a following way if they fit into single option space of a 509 single TCP header. 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |Kind | Length |ExID| Flags | Key Index |first block of 16 bytes | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Kind, Length, ExID remains same as described in section 2.1. 516 Options data constitutes the Flags and the variable length data. 517 Flags: Type of cipher text T-bit set to 1, only one block Frag= 000. 518 Key Index is the index used in encryption 520 Cipher text layout in the TCP options without fragmentation 522 Figure 5 524 The flag field of the common option header indicates that the content 525 is cipher text by having the T bit set to one. Since the ciphered 526 block is not fragmented the Frag-bits of the flag field are set to 527 zero (Frag= 000). (Use of Seq bits is left for later submissions). 528 If there is not enough space to accommodate the 16 bytes in the 529 option data, the data is fragmented. 531 If there are multiple cipher text blocks of 16 bytes, the flag field 532 shows the type of the option being cipher text with the T-bit set to 533 one, and by Frag-field showing the fragment number starting from 001 534 and incremented by one for each subsequent fragment of a packet of 535 the same type. For the last fragment, the Frag-field is always 536 binary 111 to indicate the last fragment. 538 First fragment: 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 541 |Kind |Length|ExID|Flags| Total Length|KeyIndex|1. block|fragmented block| 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 544 Kind, Length, ExID remains same as described in section 2.1 545 Options data constitutes the Flags, Total Length, Key Index and the variable length data. 546 Flags: Type of cipher text T-bit = 1, Frag field = 001 first fragment 547 Total Length: total number of bytes of option data to be fragmented 548 Key Index is the index used in encryption 550 Second fragment if the last one: 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |Kind | Length | ExID |Flags| Key Index | Rest of the fragmented block | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Kind, Length, ExID remains same as described in section 2.1 557 Options data constitutes the Flags, Key Index and the variable length data. 558 Flags: Type of cipher text T-bit = 1, Frag field = 111 last fragment, otherwise 010. 559 Total Length: total number of bytes in the fragments 560 Key Index is the index used in encryption 562 Cipher text layout extending to two consecutive headers 564 Figure 6 566 2.4. Nonce (Initialization Vector) 568 The 16 byte Nonce (or IV) is transmitted along with the cipher text 569 to protect against de-synchronization between the encryption- 570 decryption points. 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |Kind | Length | ExID |Flags| Key Index | Nonce (IV) 16 bytes | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Kind, Length, ExID remains same as described in section 2.1 577 Options data constitutes the Flags and the variable length data. 578 Flags: Type of IV/Nonce P-bit set to 1, only one block Frag= 000 579 Key Index is the index used in encryption 581 Nonce (IV) in a single header 583 Figure 7 585 If the Nonce (IV) doesn't fit into the remaining free bytes of the 586 option field it needs to be fragmented using the Frag-field in the 587 same way as cipher text layout is extending across two or more 588 consecutive TCP headers but with the option type field set to 589 indicate Nonce/IV by P-bit set to 1. 591 2.5. Authentication 593 The authentication covers the cipher text, the Nonce (IV) and 594 includes additional TCP protocol header fields to protect against 595 replay attacks. The authentication uses HMAC codes (e.g. HMAC- 596 SHA2-224), 128 bits (16 bytes) key size, 224 bits (28 bytes) digest 597 size. Multiple keys (at most 256) for authentication with the same 598 information receiver can be used. The keys MUST be different from 599 those used for encryption. Truncation is possible but at least 160 600 bits (20 bytes) must be used from the digest to meet the typical 601 security level of mobile networks. 603 Authentication takes a key, the input (arbitrary length) and produces 604 a 28 byte long digest, which is truncated to 20 bytes (keeping the 605 most significant bytes). The HMAC algorithm and truncation can be 606 negotiated via key management (out of scope of this document). 608 The authentication covers the TCP sequence number, ACK number, and 609 TimeStamp (TSval, TSecr not the possible 2 bytes of padding) fields 610 of the TCP header as well as the Common Kind-Length-ExID-header with 611 its data in all cipher text option and IV/Nonce option packets. (The 612 Authentication type options itself cannot be covered by the 613 authentication.) 615 The order in which the fields are included into the message 616 authentication code is the following. From the TCP header: TCP Seq, 617 ACK, TSval, TSecr. Followed by the following fields from the 618 ciphered text: Kind, Length, ExID, Flags, Key Index, cipher text, and 619 from the IV/Nonce type of option packets TCP Seq, ACK, TSval, TSecr 620 (note cipher text and IV/Nonce type of options may be in different 621 TCP packets) followed by Kind, Length, ExID, Flags, Key Index, Nonce/ 622 IV. 624 In case the option packets used as input to the HMAC are fragmented 625 into multiple TCP headers, they are processed so that headers with 626 cipher text option are processed first, followed by IV/Nonce option 627 packets. 629 The options containing the result of the HMAC are marked by setting 630 both P- and T-bits of the flag-field to one. Key Index is set to 631 point to the used authentication key, followed by the resulting 632 authentication code. If the option doesn't fit into the free option 633 space in the TCP header, it is fragmented across multiple TCP headers 634 in the same way as the cipher text options. 636 3. Applicability to Video Delivery Optimization 638 The applicability of the protocol specified in this document to 639 mobile video delivery optimization has been evaluated and tested in 640 different network load scenarios. 642 In this use case, TCP traffic, for which throughput guidance 643 information is required, passes through a Radio Analytics application 644 which resides in a Mobile-edge Computing (MEC) server (see 645 [MEC_White_Paper]). This Radio Analytics application acts as the 646 Throughput Guidance Provider and sends throughput guidance 647 information for a TCP connection using the Options field in the TCP 648 header (according to the message specification provided in section 649 2). The TCP server MAY use this information to assist TCP congestion 650 control decisions as described above. The information MAY also be 651 used to select the application level coding so that it matches the 652 estimated capacity at the radio downlink for that TCP connection. 654 All of these improvements aim to enhance the quality of experience of 655 the end user by reducing the time-to-start of the content as well as 656 video stall occurrences. 658 3.1. Test Results 660 Nokia Networks and Google tested the video delivery optimization use 661 case in a live production LTE network. Google server was placed 662 close to the packet core network of LTE (SGi-interface of LTE). 663 Different network load scenarios were taken into consideration. TCP 664 Cubic was used in these tests [MTG_ICCRG]. 666 Field trial preformance results 668 +-------------------+-----------------------+-----------------------+ 669 | Performance | Difference of | Diff of 99th | 670 | metric | Averages (%) | percentiles | 671 +-------------------+-----------------------+-----------------------+ 672 | Time to play | -8.0% | -12% | 673 | Number of formats | +4.1% | +29.9% | 674 | Client bandwidth | +0.7% | +8.0% | 675 | Ave Video | +6.2% | +5.6% | 676 | resolution | | | 677 | Re-buffer time | -19.7% | -5.1% | 678 +-------------------+-----------------------+-----------------------+ 680 Table 2: Performance Data 682 These user experience improvements results into better video play and 683 are likely to offer longer battery life. 685 4. Manageability considerations 687 The application in the RAN SHOULD be configured with a list of 688 destinations to which throughput guidance should be provided. The 689 application in RAN will supply mobile throughput guidance information 690 to more than one TCP server simultaneously based on the list of 691 destinations. 693 In addition, it SHOULD be possible to configure the frequency (in 694 milliseconds) at which throughput guidance needs to be signaled as 695 well as the required security level and parameters for the encryption 696 and the authentication if supported. 698 5. Security considerations 700 Throughput guidance is considered confidential information and it 701 SHOULD be provided in a secure way. The information can be provided 702 as plain text in a secure and closed network (e.g. inside operator 703 network). In other cases, the information should be authenticated 704 and encrypted at the TCP-header level (between the Throughput 705 Guidance Provider and the TCP server). 707 Section 2 described how the TCP Header information can be signed and 708 encrypted for security purposes. An out-of-band mechanism is 709 currently used to agree upon the set of keys used to encrypt and 710 authenticate the messages exchanged between the endpoint and the 711 network element that generates the throughput guidance headers. 713 As stated in [Req_Arch_MTG_Exposure], the policy configuration of the 714 Throughput Guidance Provider and the server endpoint, as well as the 715 key management and the encryption algorithm are beyond the scope of 716 this protocol definition. The protocol assumes that a trustful 717 relationship has been formed between the Throughput Guidance Provider 718 and the TCP server and that the required security level is already 719 configured by the operator and agreed between the entities ( i.e. 720 authentication, encryption or both). 722 The identity of the Mobile Throughput Guidance provider that injects 723 the throughput guidance header must be explicitly known to the 724 endpoint receiving the information. Omitting such information would 725 enable malicious third parties to inject erroneous information. 727 Fortunately, the issue of malicious disinformation can be easily 728 addressed using well known techniques. First, the network entity 729 responsible for injecting the throughput guidance header can encrypt 730 the header and include a cryptographically secure message 731 authentication code. In this way the transport endpoint that 732 receives the throughput guidance header can check that the 733 information was sent by a legitimate entity and that the information 734 has not been tampered with. 736 Furthermore, the throughput guidance information should be treated 737 only as an estimate to the congestion control algorithm running at 738 the transport endpoint. The endpoint that receives this information 739 should not assume that it is always correct and accurate. 740 Specifically, endpoints should check the validity of the information 741 received and if they find it erroneous they should discard it and 742 possibly take other corrective actions (e.g., discard all future 743 throughput guidance information from a particular IP prefix). 745 The impact of TCP Authentication Option (TCP-AO) with encrypted TCP 746 segment payload [tcp-ao-encrypt] implies that the Throughput Guidance 747 Provider functional element acts as a full back to back TCP proxy. 748 This case is left for later stages as the work [tcp-ao-encrypt] is 749 still at draft stage. 751 6. IANA considerations 753 In the current version of the document and for field tests, the 754 experimental value 253 is used for the "Throughput Guidance" TCP 755 option kind. ExpID SHOULD be set to 0x6006 (16 bits) 757 7. Acknowledgements 759 8. References 761 8.1. Normative References 763 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 764 RFC 793, DOI 10.17487/RFC0793, September 1981, 765 . 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, 769 DOI 10.17487/RFC2119, March 1997, 770 . 772 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 773 RFC 6994, DOI 10.17487/RFC6994, August 2013, 774 . 776 8.2. Informative References 778 [I-D.narten-iana-considerations-rfc2434bis] 779 Narten, T. and H. Alvestrand, "Guidelines for Writing an 780 IANA Considerations Section in RFCs", draft-narten-iana- 781 considerations-rfc2434bis-09 (work in progress), March 782 2008. 784 [MEC_White_Paper] 785 ETSI, "Mobile-Edge Computing - Introductory Technical 786 White Paper", 2014. 788 [MTG_ICCRG] 789 Szilagyi, P., and Terzis, A., "Mobile Content Delivery 790 Optimization based on Throughput Guidance", Presentation 791 at ICCRG meeting IETF93 (work in progress), July 2015. 793 [Req_Arch_MTG_Exposure] 794 Jain, A., , Terzis, A., , Sprecher, N., , Arunachalam, S., 795 , Smith, K., , and G. Klas, "Requirements and reference 796 architecture for Mobile Throughput Guidance Exposure", 797 draft-sprecher-mobile-tg-exposure-req-arch-01.txt (work in 798 progress), February 2015. 800 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 801 DOI 10.17487/RFC2629, June 1999, 802 . 804 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 805 of Explicit Congestion Notification (ECN) to IP", 806 RFC 3168, DOI 10.17487/RFC3168, September 2001, 807 . 809 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 810 Text on Security Considerations", BCP 72, RFC 3552, 811 DOI 10.17487/RFC3552, July 2003, 812 . 814 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 815 DOI 10.17487/RFC4413, March 2006, 816 . 818 [RFC5935] Ellison, M. and B. Natale, "Expressing SNMP SMI Datatypes 819 in XML Schema Definition Language", RFC 5935, 820 DOI 10.17487/RFC5935, August 2010, 821 . 823 [tcp-ao-encrypt] 824 Touch, J., , "A TCP Authentication Option Extension for 825 Payload Encryption", draft-touch-tcp-ao-encrypt- 826 02.txt (work in progress), November 2014. 828 [tcp-edo] Touch, J., and Eddy, W., "TCP Extended Data Offset 829 Option", draft-ietf-tcpm-tcp-edo-01.txt (work in 830 progress), October 2013. 832 Appendix A. 834 Authors' Addresses 836 Ankur Jain 837 Google 838 1600 Amphitheatre Parkway 839 Mountain View, CA 94043 840 US 842 Phone: +1-925-526-5879 843 Email: jankur@google.com 844 Andreas Terzis 845 Google 846 1600 Amphitheatre Parkway 847 Mountain View, CA 94043 848 US 850 Phone: +1-650-214-5270 851 Email: aterzis@google.com 853 Hannu Flinck 854 Nokia Networks 855 Espoo 856 FI 858 Phone: +358504839522 859 Email: hannu.flinck@nokia.com 861 Nurit Sprecher 862 Nokia Networks 863 Hod HaSharon 864 IL 866 Phone: +97297751229 867 Email: nurit.sprecher@nokia.com 869 Swaminathan Arunachalam 870 Nokia Networks 871 Irving, TX 872 US 874 Phone: +19723303204 875 Email: swaminathan.arunachalam@nokia.com 877 Kevin Smith 878 Vodafone 879 One Kingdom Street, Paddington Central 880 London W2 6BY 881 UK 883 Phone: +19723303204 884 Email: kevin.smith@vodafone.com