One document matched: draft-flinck-mobile-throughput-guidance-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4413 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4413.xml">
<!ENTITY RFC5935 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5935.xml">
<!ENTITY RFC6994 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6994.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-flinck-mobile-throughput-guidance-03.txt" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Mobile Throughput Guidance">Mobile Throughput Guidance Inband Signaling Protocol
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ankur Jain" initials="A.J."
surname="Jain">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<!-- Reorder these if your country does things differently -->
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<phone>+1-925-526-5879</phone>
<email>jankur@google.com</email>
</address>
</author>
<author fullname="Andreas Terzis" initials="A.T."
surname="Terzis">
<organization>Google</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<!-- Reorder these if your country does things differently -->
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<phone>+1-650-214-5270</phone>
<email>aterzis@google.com</email>
</address>
</author>
<author fullname="Hannu Flinck" initials="H.F."
surname="Flinck">
<organization>Nokia Networks</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Espoo</city>
<region></region>
<code></code>
<country>FI</country>
</postal>
<phone>+358504839522</phone>
<email>hannu.flinck@nokia.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Nurit Sprecher" initials="N.S."
surname="Sprecher">
<organization>Nokia Networks</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Hod HaSharon</city>
<region></region>
<code></code>
<country>IL</country>
</postal>
<phone>+97297751229</phone>
<email>nurit.sprecher@nokia.com</email>
</address>
</author>
<author fullname="Swaminathan Arunachalam" initials="S.A."
surname="Arunachalam">
<organization>Nokia Networks</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Irving</city>
<region>TX</region>
<code></code>
<country>US</country>
</postal>
<phone>+19723303204</phone>
<email>swaminathan.arunachalam@nokia.com</email>
</address>
</author>
<author fullname="Kevin Smith" initials="K.S."
surname="Smith">
<organization>Vodafone</organization>
<address>
<postal>
<street>One Kingdom Street, Paddington Central</street>
<!-- Reorder these if your country does things differently -->
<city>London</city>
<region></region>
<code>W2 6BY</code>
<country>UK</country>
</postal>
<phone>+19723303204</phone>
<email>kevin.smith@vodafone.com</email>
</address>
</author>
<date month="September" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport Area</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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 <xref target="Req_Arch_MTG_Exposure" />.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The problem statement related to the behavior of the TCP in cellular
networks is provdied in <xref target="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.
</t>
<t>
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
<xref target="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.
</t>
<section title="Contributing Authors">
<t>
The editors gratefully acknowledge the following additional contributors: Peter Szilagyi/Nokia,
Csaba Vulkan/Nokia, Ram Gopal/Nokia, Guenter Klas/Vodafone and Peter Cosimini/Vodafone.
</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Acronyms and Abbreviations">
<texttable align="left" style="none">
<preamble>This document uses the following acronyms:</preamble>
<ttcol align="left"></ttcol>
<ttcol align="left"></ttcol>
<c>ECGI</c>
<c>E-UTRAN Cell Global Identifier format</c>
<c>ECN</c>
<c>Explicit Congestion Notification</c>
<c>HMAC</c>
<c>Hash-based Message Authentication Code</c>
<c>HTTP </c>
<c> Hypertext Transfer Protocol </c>
<c> HTTPS </c>
<c> Hypertext Transfer Protocol Secure </c>
<c>IP</c>
<c>Internet Protocol</c>
<c>IV</c>
<c>Initialization Vector</c>
<c>LTE</c>
<c>Long Term Evolution</c>
<c>MTG</c>
<c>Mobile Throughput Guidance</c>
<c>RAN</c>
<c>Radio Access Network</c>
<c> RCTP </c>
<c> RTP Control Protocol </c>
<c>RTT</c>
<c>Round Trip Time</c>
<c>SACK</c>
<c>Selective Acknowledgement</c>
<c>TCP</c>
<c>Transmission Control Protocol</c>
<c> TCP-EDO </c>
<c> TCP Extended Data option </c>
<c> TG </c>
<c> Throughput Guidance </c>
<c>UE</c>
<c>User Equipment</c>
</texttable>
</section>
<section title= "Definitions">
<t>Throughput Guidance Provider: <list
hangIndent="10" style="empty">
<t>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</t>
</list></t>
</section>
<section title="Assumptions and Considerations for the Solution">
<t>
This document specifies a solution protocol that is compliant with
the requirements and architecture specified in
<xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
This solution specified in this document also satisfies the following
assumptions and considerations:
<list style="symbols">
<t> The end-to-end traffic is delivered via HTTP. </t>
<t> 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. </t>
<t> TCP is used to deliver the HTTPS traffic. </t>
<t> The Real-time Transport Protocol (RTP) network protocol is not
used for traffic delivery. </t>
</list>
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
In particular, the Throughput Guidance Providers adds the throughput
guidance information to the Options field of the TCP header (see RFC
0793 <xref target="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 <xref target="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.
</t>
<t>
Note that once standardized and implemented, TCP Extended Data option
(TCP-EDO) can be used to carry the throughput guidance information as
specified in <xref target="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.
</t>
</section>
</section>
<section title="Protocol">
<t>
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.
</t>
<t>
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
<xref target="Req_Arch_MTG_Exposure" />.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref target="Req_Arch_MTG_Exposure" />).
</t>
<t>
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.
</t>
<t>
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 <xref target="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.
</t>
<section title="Common Kind-Length-Value header">
<t>
Mobile Throughput Guidance Signaling uses the common TCP options
structure as in <xref target="RFC0793"/> with experimental identifier as defined in
<xref target="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.
</t>
<figure align="center" anchor="xml_common_kind">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Kind | Length | ExID |Flags| variable length data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="hanging">
<t hangText=" Kind:">
<vspace blankLines="1"/>
Code point 253 for Experimental Opition for 16-bit ExID [RFC6994].
The size of this field is 1 byte.
</t>
<t hangText=" Length:">
<vspace blankLines="1"/>
A 1 byte field, length of the option in bytes as defined in
RFC793.
</t>
<t hangText=" ExID:">
<vspace blankLines="1"/>
Two bytes Experimental Identifier according to [RFC6994]. Code
point 0x6006.
</t>
<t hangText=" Flags:">
<vspace blankLines="1"/>
One byte of MTG protocol flag field as defined below.
<figure align="center" anchor="xml_flags">
<artwork align="left"><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Seq |Frag |P|T|
+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble> Flag field of common Kind-Lenght-Value header </postamble>
</figure>
</t>
<t hangText=" Seq:">
<vspace blankLines="1"/>
Three-bit sequence number that maintains context across different
packet types as defined by P- and T-bits below. The scope of the
sequence number is to protect against packet reordering, not to
provide a globally unique identifier or sequence number. The use
of these bits are reserved for possible transfer mode extensions.
</t>
<t hangText=" Frag:">
<vspace blankLines="1"/>
Three bits that provide information about how to reassemble
information if fragmented into multiple packets. If no
fragmentation across multiple TCP packet headers is needed, these
bits are set to zero. Otherwise, Frag is a counter starting from
1 and incremented by 1 for each subsequent packet of the same type
(see P- and T-bits below). For the last fragment, the Fragment is
always 7 (binary 111) to indicate that the information is
complete.
</t>
<t hangText=" P and T bits:">
<vspace blankLines="1"/>
These two bits encode the packet type: Plaintext (P=0, T= 0),
Cipher text (P=0, T=1), Nonce (IV) (P=1, T=0) or Authentication
(P=1, T=1). For Plaintext, the Fragment bits are always zero.
</t>
<t hangText="
Variable length data:">
<vspace blankLines="1"/>
The variable length content (i.e. option data) in <type, value>
format. The content depends of the transfer mode as defined in
the following sections of this document. If the option data is
fragmented across multiple headers the first fragment (marked with
Frag=001 in the Flags-field) contains "Total Length of Data"-field
that is the length of the variable data of MTG in all the
fragments. Total Length of Data field is followed the content in
<type, value>-format
</t>
</list>
</t>
<t>
As an example for the use of the Flags-field, consider a cipher text
of a single block. For it the T-bit is set to one, P-bit is set to
zero, Fragment and Seq-fields are zero in the Flags-field. In case
the cipher text option cannot fit into a single TCP packet option,
the cipher text is fragmented across multiple TCP headers. The first
fragment has value Frag= 001, and the value is incremented for each
subsequent fragment. The first fragment contains the "Total Length
of Data"-field indicating the total length of the data to be
fragmented. Last fragment is marked with all Frag-bits set to 1
(Frag= 111 for the last fragment). Therefore, the maximum number of
fragments is seven. Details follow in the next sections.
</t>
</section>
<section title="Plain text mode Throughput Guidance Options">
<t>
The plain text mode can be used in secure and closed networks or with
information that has no confidentiality requirement. The plain text
mode is made of one or more type-value pairs. The type determines
the length of the following value.
</t>
<texttable anchor="table_1" title="MTG type-vale pairs">
<preamble>Table of Type Value pairs of Throughput Guidance option data</preamble>
<ttcol align="center">Name</ttcol>
<ttcol align="center">Type</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="center">Unit of the type</ttcol>
<c>Throughput Guidance</c>
<c> 1 </c>
<c>2 bytes </c>
<c>Mbits/s</c>
</texttable>
<t>
The Type 1 element carries the actual throughput estimate in the
16-bit value field The throughput value is encoded using a fixed-
point number representation. The 12 most significant bits are used
for the integer value while the bottom 4 bits correspond to the
decimal portion of the throughput value. Throughput is expressed in Megabits per second.
</t>
<t>
The type-value pair elements are laid out consecutively in the header. At the end padding (i.e., the NO-OP TCP
Option header with kind equal to 1, or the End of Option List TCP Option header with kind equal to 0) may be required
to align the header size to the multiple of 4 bytes (required by the TCP standard). All bits in the Flag field are
set to zero.
</t>
<figure align="center" anchor="xml_plaintext">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
]]></artwork>
<postamble>Layout of plain text option data in the TCP header options space.</postamble>
</figure>
</section>
<section title="Encrypted mode">
<t>
Encryption requires authentication for integrity protection, as it is insecure to use encryption
without it. Thus, the encrypted mode contains authentication as well. Encryption and authentication must use
different keys. The following diagram shows the encryption process.
</t>
<figure align="center" anchor="xml_encryption">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ | key1 | |IV(Nonce)|
|key index| --> +-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+-+ | key 2 | |
+-+-+-+-+ key +-+-+-V-+-+-+-+
... ----> | AES 128-CNT|
+-+-+-+-+ +-+-+-+-+-+-+-+
| key n | |
+-+-+-+-+ +<------ Plain text
|
+-+-+-V-+-+-+-+
| Cipher text |
+-+-+-+-+-+-+-+
]]></artwork>
<postamble>Encryption method</postamble>
</figure>
<t>
The encryption uses Advanced Encryption Standard (AES), 128 bits (16
bytes) block size, 128 bits (16 bytes) key size, Counter (CTR) block
cipher mode. Integrity protection with CTR mode is MUST; this is
provided via HMAC based message authentication (see Authentication
section below).
</t>
<t>
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.
</t>
<t>
The Nonce is 16 bytes. A unique Nonce is generated for each
encrypted block. The same Initialization Vector, IV or Nonce MUST
NOT be used with the same encryption key more than once. This is to
be enforced by the Throughput Guidance Provider; otherwise security
scheme will be broken.
</t>
<t>
The resulting cipher text is in blocks of 16 bytes. The cipher text
blocks are packed into the option space together with the used Key
Index in a following way if they fit into single option space of a
single TCP header.
</t>
<figure align="center" anchor="xml_ciphertext">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
]]></artwork>
<postamble>Cipher text layout in the TCP options without fragmentation</postamble>
</figure>
<t>
The flag field of the common option header indicates that the content
is cipher text by having the T bit set to one. Since the ciphered
block is not fragmented the Frag-bits of the flag field are set to
zero (Frag= 000). (Use of Seq bits is left for later submissions).
If there is not enough space to accommodate the 16 bytes in the
option data, the data is fragmented.
</t>
<t>
If there are multiple cipher text blocks of 16 bytes, the flag field
shows the type of the option being cipher text with the T-bit set to
one, and by Frag-field showing the fragment number starting from 001
and incremented by one for each subsequent fragment of a packet of
the same type. For the last fragment, the Frag-field is always
binary 111 to indicate the last fragment.
</t>
<figure align="center" anchor="xml_cipher_fragment">
<preamble></preamble>
<artwork align="left"><![CDATA[
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
]]></artwork>
<postamble>Cipher text layout extending to two consecutive headers</postamble>
</figure>
</section>
<section title=" Nonce (Initialization Vector)">
<t>
The 16 byte Nonce (or IV) is transmitted along with the
cipher text to protect against de-synchronization between the encryption-decryption
points.
</t>
<figure align="center" anchor="xml_nonce">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
]]></artwork>
<postamble>Nonce (IV) in a single header</postamble>
</figure>
<t>
If the Nonce (IV) doesn't fit into the remaining free bytes of the
option field it needs to be fragmented using the Frag-field in the
same way as cipher text layout is extending across two or more
consecutive TCP headers but with the option type field set to
indicate Nonce/IV by P-bit set to 1.
</t>
</section>
<section title=" Authentication">
<t>
The authentication covers the cipher text, the Nonce (IV) and
includes additional TCP protocol header fields to protect against
replay attacks. The authentication uses HMAC codes (e.g. HMAC-
SHA2-224), 128 bits (16 bytes) key size, 224 bits (28 bytes) digest
size. Multiple keys (at most 256) for authentication with the same
information receiver can be used. The keys MUST be different from
those used for encryption. Truncation is possible but at least 160
bits (20 bytes) must be used from the digest to meet the typical
security level of mobile networks.
</t>
<t>
Authentication takes a key, the input (arbitrary length) and produces
a 28 byte long digest, which is truncated to 20 bytes (keeping the
most significant bytes). The HMAC algorithm and truncation can be
negotiated via key management (out of scope of this document).
</t>
<t>
The authentication covers the TCP sequence number, ACK number, and
TimeStamp (TSval, TSecr not the possible 2 bytes of padding) fields
of the TCP header as well as the Common Kind-Length-ExID-header with
its data in all cipher text option and IV/Nonce option packets. (The
Authentication type options itself cannot be covered by the
authentication.)
</t>
<t>
The order in which the fields are included into the message
authentication code is the following. From the TCP header: TCP Seq,
ACK, TSval, TSecr. Followed by the following fields from the
ciphered text: Kind, Length, ExID, Flags, Key Index, cipher text, and
from the IV/Nonce type of option packets TCP Seq, ACK, TSval, TSecr
(note cipher text and IV/Nonce type of options may be in different
TCP packets) followed by Kind, Length, ExID, Flags, Key Index, Nonce/
IV.
</t>
<t>
In case the option packets used as input to the HMAC are fragmented
into multiple TCP headers, they are processed so that headers with
cipher text option are processed first, followed by IV/Nonce option
packets.
</t>
<t>
The options containing the result of the HMAC are marked by setting
both P- and T-bits of the flag-field to one. Key Index is set to
point to the used authentication key, followed by the resulting
authentication code. If the option doesn't fit into the free option
space in the TCP header, it is fragmented across multiple TCP headers
in the same way as the cipher text options.
</t>
</section>
</section>
<section title="Applicability to Video Delivery Optimization">
<t>
The applicability of the protocol specified in this document to
mobile video delivery optimization has been evaluated and tested in
different network load scenarios.
</t>
<t>
In this use case, TCP traffic, for which throughput guidance
information is required, passes through a Radio Analytics application
which resides in a Mobile-edge Computing (MEC) server (see
<xref target="MEC_White_Paper" />). This Radio Analytics application acts as the
Throughput Guidance Provider and sends throughput guidance
information for a TCP connection using the Options field in the TCP
header (according to the message specification provided in section
2). The TCP server MAY use this information to assist TCP congestion
control decisions as described above. The information MAY also be
used to select the application level coding so that it matches the
estimated capacity at the radio downlink for that TCP connection.
</t>
<t>
All of these improvements aim to enhance the quality of experience of the end user
by reducing the time-to-start of the content as well as video stall occurrences.
</t>
<section title="Test Results">
<t>
Nokia Networks and Google tested the video delivery optimization use
case in a live production LTE network. Google server was placed close to the packet
core network of LTE (SGi-interface of LTE).
Different network load scenarios
were taken into consideration. TCP Cubic was used in these tests
<xref target="MTG_ICCRG" />.
</t>
<texttable anchor="table_2" title="Performance Data">
<preamble>Field trial preformance results</preamble>
<ttcol align="center">Performance metric</ttcol>
<ttcol align="center">Difference of Averages (%)</ttcol>
<ttcol align="center">Diff of 99th percentiles</ttcol>
<c>Time to play</c>
<c> -8.0%</c>
<c>-12%</c>
<c>Number of formats</c>
<c> +4.1%</c>
<c>+29.9%</c>
<c>Client bandwidth</c>
<c> +0.7%</c>
<c>+8.0%</c>
<c>Ave Video resolution</c>
<c> +6.2%</c>
<c>+5.6%</c>
<c>Re-buffer time</c>
<c>-19.7%</c>
<c>-5.1%</c>
</texttable>
<t>
These user experience improvements results into better video play and are likely to offer longer battery life.
</t>
</section>
</section>
<section title="Manageability considerations">
<t>
The application in the RAN SHOULD be configured with a list of
destinations to which throughput guidance should be provided. The
application in RAN will supply mobile throughput guidance information
to more than one TCP server simultaneously based on the list of
destinations.
</t>
<t>
In addition, it SHOULD be possible to configure the frequency (in
milliseconds) at which throughput guidance needs to be signaled as
well as the required security level and parameters for the encryption
and the authentication if supported.
</t>
</section>
<section title="Security considerations">
<t>
Throughput guidance is considered confidential information and it
SHOULD be provided in a secure way. The information can be provided
as plain text in a secure and closed network (e.g. inside operator
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).
</t>
<t>
Section 2 described how the TCP Header information can be signed and
encrypted for security purposes. An out-of-band mechanism is
currently used to agree upon the set of keys used to encrypt and authenticate
the messages exchanged between the endpoint and the
network element that generates the throughput guidance headers.
</t>
<t>
As stated in <xref target="Req_Arch_MTG_Exposure" />, the policy configuration of the
Throughput Guidance Provider and the server endpoint, as well as the
key management and the encryption algorithm are beyond the scope of
this protocol definition. The protocol assumes that a trustful
relationship has been formed between the Throughput Guidance Provider
and the TCP server and that the required security level is already
configured by the operator and agreed between the entities ( i.e.
authentication, encryption or both).
</t>
<t>
The identity of the Mobile Throughput Guidance provider that injects
the throughput guidance header must be explicitly known to the
endpoint receiving the information. Omitting such information would
enable malicious third parties to inject erroneous information.
</t>
<t>
Fortunately, the issue of malicious disinformation can be easily
addressed using well known techniques. First, the network entity
responsible for injecting the throughput guidance header can encrypt
the header and include a cryptographically secure message
authentication code. In this way the transport endpoint that
receives the throughput guidance header can check that the
information was sent by a legitimate entity and that the information
has not been tampered with.
</t>
<t>
Furthermore, the throughput guidance information should be treated
only as an estimate to the congestion control algorithm running at
the transport endpoint. The endpoint that receives this information
should not assume that it is always correct and accurate.
Specifically, endpoints should check the validity of the information
received and if they find it erroneous they should discard it and
possibly take other corrective actions (e.g., discard all future
throughput guidance information from a particular IP prefix).
</t>
<t>
The impact of TCP Authentication Option (TCP-AO) with encrypted TCP
segment payload <xref target="tcp-ao-encrypt" /> implies that the Throughput Guidance
Provider functional element acts as a full back to back TCP proxy.
This case is left for later stages as the work [tcp-ao-encrypt] is
still at draft stage.
</t>
</section>
<section title="IANA considerations">
<t>
In the current version of the document and for field tests, the
experimental value 253 is used for the "Throughput Guidance" TCP
option kind. ExpID SHOULD be set to 0x6006 (16 bits)
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<!-- Possibly a 'Contributors' section ... -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC793;
&RFC6994;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
&RFC4413;
&RFC3168;
&RFC5935;
&I-D.narten-iana-considerations-rfc2434bis;
<!-- A reference written by by an organization not a person. -->
<reference anchor="MEC_White_Paper">
<front>
<title>Mobile-Edge Computing - Introductory Technical White Paper</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="Req_Arch_MTG_Exposure">
<front>
<title>Requirements and reference architecture for Mobile Throughput Guidance Exposure </title>
<author surname= "Jain, A.">
</author>
<author surname= "Terzis, A.">
</author>
<author surname= "Sprecher, N.">
</author>
<author surname= "Arunachalam, S.">
</author>
<author surname= "Smith, K.">
</author>
<author surname= "G. Klas">
</author>
<date month="February" year="2015"/>
</front>
<seriesInfo name="draft-sprecher-mobile-tg-exposure-req-arch-01.txt" value="(work in progress)"/>
</reference>
<reference anchor="tcp-ao-encrypt">
<front>
<title>A TCP Authentication Option Extension for Payload Encryption </title>
<author surname= "Touch, J.">
</author>
<date month="November" year="2014"/>
</front>
<seriesInfo name="draft-touch-tcp-ao-encrypt-02.txt" value="(work in progress)"/>
</reference>
<reference anchor="tcp-edo">
<front>
<title>TCP Extended Data Offset Option </title>
<author surname= "Touch, J.">
</author>
<author surname= "Eddy, W.">
</author>
<date month="October" year="2013"/>
</front>
<seriesInfo name="draft-ietf-tcpm-tcp-edo-01.txt" value="(work in progress)"/>
</reference>
<reference anchor="MTG_ICCRG">
<front>
<title>Mobile Content Delivery Optimization based on Throughput Guidance </title>
<author surname= "Szilagyi, P.">
</author>
<author surname= "Terzis, A.">
</author>
<date month="July" year="2015"/>
</front>
<seriesInfo name="Presentation at ICCRG meeting IETF93" value="(work in progress)"/>
</reference>
</references>
<section anchor="app-additional" title=" ">
<t></t>
</section>
<!-- Change Log
v00 2014-10-26 HF First version
v02 2015-03-09 HF Update to security considerations and test results
v03 2015-09-07 HF Update to test results
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:53:15 |