Mobile Throughput Guidance Inband Signaling Protocol
draft-flinck-mobile-throughput-guidance-03.txt

Abstract

The bandwidth available for end user devices in cellular networks can vary by an order of magnitude over a few seconds due to changes in the underlying radio channel conditions, as device mobility and changes in system load as other devices enter and leave the network. Furthermore, packets losses are not always signs of congestion. The Transmission Control Protocol (TCP) can have difficulties adapting to these rapidly varying conditions leading to inefficient use of a cellular network's resources and degraded application performance. Problem statement, requirements and the architecture for a solution is documented in [Req_Arch_MTG_Exposure].

This document proposes a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server. This "Throughput Guidance" (TG) information would indicate the throughput estimated to be available at the radio downlink interface (between the Radio Access Network (RAN) and the mobile device (UE)). TCP server can use this TG information to ensure high network utilization and high service delivery performance. The document describes the applicability of the proposed mechanism for video delivery over cellular networks; it also presents test results from live operator's environment.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 11, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Contributing Authors
• 1.2. Terminology
• 1.3. Acronyms and Abbreviations
• 1.4. Definitions
• 1.5. Assumptions and Considerations for the Solution
• 2. Protocol
• 2.1. Common Kind-Length-Value header
• 2.2. Plain text mode Throughput Guidance Options
• 2.3. Encrypted mode
• 2.4. Nonce (Initialization Vector)
• 2.5. Authentication
• 3. Applicability to Video Delivery Optimization
• 3.1. Test Results
• 4. Manageability considerations
• 5. Security considerations
• 6. IANA considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A.
• Authors' Addresses

1. Introduction

The problem statement related to the behavior of the TCP in cellular networks is provdied in [Req_Arch_MTG_Exposure]. That same document specifies the requirements, reference architecture and proposed solution principles for a mobile throughput guidance exposure mechanism that can be used to assist TCP in cellular networks, ensuring high utilization and high service delivery performance.

This document presents a set of considerations and assumptions for the development of a solution. It specifies a protocol that addresses the requirements and the architecture stated in the [Req_Arch_MTG_Exposure]. This document describes also the applicability of the proposed mechanism to video delivery over cellular networks with test results from live production environment.

1.1. Contributing Authors

The editors gratefully acknowledge the following additional contributors: Peter Szilagyi/Nokia, Csaba Vulkan/Nokia, Ram Gopal/Nokia, Guenter Klas/Vodafone and Peter Cosimini/Vodafone.

1.2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.3. Acronyms and Abbreviations

This document uses the following acronyms:

1.4. Definitions

Throughput Guidance Provider:

• A functional element in the RAN that signals to the TCP server the information on the (near-real time) throughput estimated to be available at the radio downlink interface

1.5. Assumptions and Considerations for the Solution

This document specifies a solution protocol that is compliant with the requirements and architecture specified in [Req_Arch_MTG_Exposure]. The protocol is used by the cellular network to provide throughput guidance information to the TCP server; this information indicates the throughput estimated to be available at the radio downlink interface for the TCP connection. The protocol allows the information to be provided in near real time in situations where the network conditions are changing frequently or the user is moving.

While the implementation details can vary according to the access technology, the resource allocation is abstracted as the capacity of the "radio link" between the RAN and the UE. For example, in the case of an LTE network, the number of physical resource blocks allocated to a UE, along with the modulation scheme and coding rate used, can be translated into radio link capacity in Megabits per second (Mbit/s). From the derived UE's total throughput and with the UE's TCP flow information, Throughput guidance for the TCP connection can be computed.

The TCP server can use this explicit information to inform several congestion control decisions. For example: (1) selecting the initial congestion window size, (2) deciding the value of the congestion window during the congestion avoidance phase, and (3) adjusting the size of the congestion window when the conditions on the "radio link" change. In other words, with this additional information, TCP neither has to congest the network when probing for available resources (by increasing its congestion window), nor rely on heuristics to decide how much it should reduce its sending rate after a congestion episode.

The same explicit information can also be used to optimize application behavior given the available resources. For example, when video is encoded in multiple bitrates, the application server can select the highest encoding rate that the network can deliver.

This solution specified in this document also satisfies the following assumptions and considerations:

• The end-to-end traffic is delivered via HTTP.
• The end-to-end traffic is encrypted (through HTTPS), thus HTTP header enrichment cannot be used by intermediate elements between the client and the server.
• TCP is used to deliver the HTTPS traffic.
• The Real-time Transport Protocol (RTP) network protocol is not used for traffic delivery.

The protocol specified in this document assumes that a trustful relationship between the Throughput Guidance Provider and the TCP server has been formed using the means discussed in the Security considerations section.

The solution in this document satisfies the considerations and the assumptions presented above, and proposes an in-band exposure mechanism where the throughput guidance information is added to the TCP headers of the relevant upstream packets. HTTP and TCP are the most prevalent protocols in the Internet, used even by the most popular streaming application. Throughput guidance at TCP level can be shared among multiple applications; it is not limited to any particular application level optimization only but it offers a generic approach that works even if application level end-to-end encryption, e.g HTTPS, is applied.

In particular, the Throughput Guidance Providers adds the throughput guidance information to the Options field of the TCP header (see RFC 0793 [RFC0793]) of packets from the TCP client to the TCP server. An in-band mechanism is proposed because it does not require a separate interface, reference value, or correlation mechanism that would be needed with out of band approaches such as with RCTP that is limited to only certain types of applications. Furthermore, an in-band mechanism can keep up with the rapid changes in the underlying radio link throughput. The proposed scheme is similar to existing mechanisms such as ECN, where an ECN- aware router sets a mark in the IP header in order to signal impending congestion (see [RFC3168]). Note, however, that the proposed scheme provides explicit information, (termed "Throughput Guidance") about the estimated throughput available for the TCP connection at the radio link between the RAN and the UE.

Note that once standardized and implemented, TCP Extended Data option (TCP-EDO) can be used to carry the throughput guidance information as specified in [tcp-edo] and simplify the use of the TCP Option fields by extending the space available for TCP options. Currently the TCP- EDO is still work in progress and not available in production. Therefore, the use of TCP-EDO to carry throughput guidance is left for the later drafts.

2. Protocol

This section describes the protocol mechanism and the information element that needs to be communicated from the RAN to the TCP remote endpoint. We describe the protocol mechanism and message format for throughput guidance. The protocol mechanism is defined in an extensible way to allow additional information to be specified and communicated. The protocol specification is based on the existing experiments and running code. It is recommended to insert the throughput guidance information to the TCP segments that flow from client to server (see reasoning in "Assumptions and Considerations" section). Most of the time, TCP segments are ACK packets from a client to the server and hence packets are unlikely to be fragmented. However, the described protocol solution can deal with fragmentation.

The Mobile Throughput Guidance Signaling message conveys information on the throughput estimated to be available at the down link path for a given TCP connection. The information is sent to the uplink end- point of the connection (i.e, the TCP server). The TCP server MAY use this information to adapt TCP behavior and to adjust application- level behavior to the link conditions as defined in [Req_Arch_MTG_Exposure].

A good example is a content optimizer or a cache that can adapt the application-level coding to match the indicated downlink radio conditions. As radio link conditions may change rapidly, this guidance information is best carried in-band using TCP options headers rather than through an out-of-band protocol.

Using the TCP options to carry throughput guidance associates the guidance information with an ongoing TCP connection and explicitly avoids separate session identification information. The proposed mechanism neither impacts the TCP state machine nor the congestion control algorithms of the TCP protocol.

The Options field enables information elements to be inserted into each packet with a 40-byte overall limit; this needs to be shared with the standardized and widely-used option elements, such as the TimeStamp and SACK. (Use of TCP-EDO will lift this constraint once available and deployed). The TCP Options field uses a Kind-Length- Value structure that enables TCP implementations to interpret or ignore information elements in the Options field based on the Kind.

In this draft, we define a Kind-Length-Value structure for encoding information about the estimated capacity of a radio access link between the RAN and the UE which is traversed by a TCP connection. The intention is to define a generic container to convey in-band information within the limited TCP Option space with optional authentication and/or encryption capabilities. Throughput guidance is the conveyed information in this document. Additional information can be specified in future.

The Throughput Guidance Provider functional element inserts Mobile Throughput Guidance TCP options only if there is enough space in the TCP header. The Throughput Guidance Provider resides on top of a radio network element see [Req_Arch_MTG_Exposure]).

Confidential information must be delivered in a secure way. The information can be provided as plain text in a secure and closed network. In other cases, the information should be authenticated and encrypted at the TCP-header level (between the Throughput Guidance Provider and the TCP server). An acceptable level of authentication and encryption (according to best common practices) may require more data than fits into a single TCP header (maximum of 40 bytes if no other options are present). As described below, fragmenting information across multiple packets will be used is such a case.

Two transfer modes are defined to deal with data confidentiality in this document; namely, plain-text mode and authenticated encryption mode. A third mode, authentication-only mode, is equally feasible. A third mode, authentication-only mode, is equally feasible and may use TCP Authentication Option (TCP-AO) (see RFC 5935 [RFC5935]). We will describe the authentication-only mode in detail in future version of this draft. Both modes share a common Kind-Length-Value "option header" structure with a flag field separating the two cases.

2.1. Common Kind-Length-Value header

Mobile Throughput Guidance Signaling uses the common TCP options structure as in [RFC0793] with experimental identifier as defined in [RFC6994]. To make Mobile Throughput Guidance Signaling extendible to different use cases a common Kind-Length-Value structure is defined below. To make Mobile Throughput Guidance Signaling extendible to different use cases a common Kind-Length-Value header is defined below.

 
	 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Kind | Length | ExID |Flags|     variable length data          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       

 
  
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       | Seq |Frag |P|T|  
       +-+-+-+-+-+-+-+-+
       
	

			 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Kind | Length |ExID|Flags |Type1|Value-1| Type2|Value-2|     ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	   Kind, Length, ExID remains same as described in section 2.1.
	   Options data constitutes the Flags and the variable length data.
	   Flags: P- and T-bits set to zero

 

			            
                   +-+-+-+-+        +-+-+-+-+-+
  +-+-+-+-+-+      | key1  |        |IV(Nonce)| 
  |key index| -->  +-+-+-+-+        +-+-+-+-+-+ 
  +-+-+-+-+-+      | key 2 |             | 
                   +-+-+-+-+  key  +-+-+-V-+-+-+-+   
                       ...   ----> |  AES 128-CNT| 
                   +-+-+-+-+       +-+-+-+-+-+-+-+ 
                   | key n |             | 
                   +-+-+-+-+             +<------ Plain text
                                         | 
                                   +-+-+-V-+-+-+-+
                                   | Cipher text |
                                   +-+-+-+-+-+-+-+										
   

			 
			 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Kind | Length |ExID| Flags | Key Index |first block of 16 bytes |    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           
       Kind, Length, ExID remains same as described in section 2.1.
       Options data constitutes the Flags and the variable length data.	   
	   Flags: Type of cipher text T-bit set to 1, only one block Frag= 000.
       Key Index is the index used in encryption	   
	 

 

		
    First fragment:         
		
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     |Kind |Length|ExID|Flags| Total Length|KeyIndex|1. block|fragmented block|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
                           
       Kind, Length, ExID remains same as described in section 2.1
           Options data constitutes the Flags, Total Length, Key Index  and the variable length data.
           Flags: Type of cipher text T-bit = 1, Frag field = 001 first fragment
       Total Length: total number of bytes of option data to be fragmented
       Key Index is the index used in encryption                       						  	

    Second fragment if the last one:         
		
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Kind | Length | ExID |Flags| Key Index | Rest of the fragmented block  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	
	    Kind, Length, ExID remains same as described in section 2.1
           Options data constitutes the Flags, Key Index and the variable length data.
           Flags: Type of cipher text T-bit = 1,  Frag field = 111 last fragment, otherwise 010.
       Total Length: total number of bytes in the fragments
       Key Index is the index used in encryption
	   	 

 

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Kind | Length | ExID |Flags| Key Index |    Nonce (IV)  16 bytes |   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+			 
 
        Kind, Length, ExID remains same as described in section 2.1
           Options data constitutes the Flags and the variable length data.
           Flags: Type of IV/Nonce P-bit set to 1, only one block Frag= 000
       Key Index is the index used in encryption