| Internet Engineering Task Force | T.A. Ayar |
| Internet-Draft | B.R. Rathke |
| Intended status: Informational | L.B. Budzisz |
| Expires: August 02, 2012 | A.W. Wolisz |
| Technical University Berlin | |
| February 2012 |
A Transparent Performance Enhancing Proxy Architecture To Enable TCP over Multiple Paths for Single-Homed Hosts
draft-ayar-transparent-sca-proxy-00
This draft complements the work of MPTCP by defining a TCP Splitter/Combiner Architecture (SCA) that enables non-MPTCP-capable single-homed hosts to benefit from the multiple paths within Internet by means of performance enhancing proxies (PEPs) placed in the access networks.
SCA Proxies (SCAPs) make use of multiple paths in a way which is completely transparent to end-hosts. Since the existence of the SCAPs is shielded from the TCP end-points, they can be deployed in the Internet as well as on the end-systems.
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 August 02, 2012.
Copyright (c) 2012 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.
Despite the fact that, the number of end-systems with multiple interfaces increases every day, usually only one interface is used to connect to the Internet, as for the single-interface hosts. This is motivated, among others, by the energy consumption. That is, the use of multiple interfaces drastically increases the power consumption and thus decreases the battery lifetime. When only one IP address is assigned to the end-system, the end-system is single-addressed.
Single addressed end-hosts may not benefit from the MPTCP [RFC6182] [RFC6356] [I-D.ietf-mptcp-multiaddressed] even if they are MPTCP-capable. MPTCP uses IP address pairs of the end-hosts to create the subflows. When two MPTCP-capable single-addressed end-systems transfer data via MPTCP, they will use regular TCP [RFC0793] like the non-MPTCP-capable hosts.
Moreover, the fact that an end-system is MPTCP-capable does not mean that MPTCP MUST be used by TCP connections. MPTCP MAY be disabled with TCP_MULTIPATH_ENABLE socket option on MPTCP-capable hosts [I-D.ietf-mptcp-api].
Nevertheless, single-addressed end-hosts may benefit from multiple paths within the Internet by means of proxies located within the access networks. Such a proxy is described in this document and called further SCA Proxy (SCAP). It detects the TCP connection and then splits and shapes TCP traffic over multiple paths. If the access network is connected to the Internet via multiple gateway (GW) links, then TCP traffic may be distributed within the access network so that the packets will leave the network from different GW links. Thus, the bandwidth aggregation of the links may be achieved. If an access network is connected to the Internet via only one GW link, the SCAP may distribute TCP traffic to multiple paths within the access network and then another SCAP on the path may combine the packets before they leave the access network.
This document describes a splitter/combiner architecture (SCA) that may be used to develop transparent proxies for TCP over multiple paths solutions. SCA is a thin layer on top of IP which captures all the TCP packets. SCA distributes data/ACK packets of a TCP connection to the multiple paths and/or combines the distributed data/ACK packets of a TCP connection from multiple paths.
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].
Single-addressed end-system: An end-system, either with single or multiple interfaces, which is assigned only one IP address to connect to the Internet.
Network Device: An access point (AP) or router located in between a TCP sender and receiver.
SCA Proxy (SCAP): A running instance of the SCA.
SCAP Device: A network device on which an instance of SCA runs.
Pipe: A network path between a network interface of a SCAP device and a network interface of another SCAP device. Pipe is uniquely identified by the IP address pair of two SCAP device interfaces.
Figure 1 shows a reference scenario for two SCAP devices in different access networks. Host A and B are single-addressed non-MPTCP-capable hosts. They are connected to the Internet via network devices which have multiple (i.e., N) GW links to the Internet. The multiple interfaces of the network devices have IP addresses A-1..N and B-1..N.
When there is a TCP connection between an application on Host A and an application on Host B, TCP packets will follow a single path (e.g., via A-1<->Pipe-1<->B-1). If the GW links have low capacities (e.g., T1 links or DSL lines), then they constitute the bottleneck for the TCP connection.
As shown in Figure 1, when network devices are used as SCAP devices they may use multiple GW links to aggregate the capacity of the links for the TCP connection:
<--Access Network 1--><-------Internet-----><--Access Network 2-->
______
+--------+ ( ) +--------+
+------+ | |_______(........)_______| | +------+
| | | Access |A-1 ( Pipe-1 ) B-1| Access | | |
| Host | | Point | : ( : ) : | Point | | Host |
| |---| or | : ( : ) : | or |---| |
| A | | Router | : ( : ) : | Router | | B |
| | | |______(..........)______| | | |
+------+ |(SCAP-1)|A-N ( Pipe-N ) B-N|(SCAP-2)| +------+
+--------+ (______) +--------+
In addition to increasing the TCP throughput, SCA aims at high deployment and adoption. To achieve that, the existence of the SCA MUST be shielded locally (i.e., from the applications and TCP on the TCP end-points) as well as on end-to-end (i.e., end points SHOULD NOT need to know which network devices are SCAP devices). Thus, SCA is designed as protocol-stack and end-host transparent.
In order to provide protocol-stack transparency, SCA MUST be located underneath the TCP. All the TCP multiple path related issues MUST be handled in the SCA which MAY be implemented as a thin layer.
SCA SHOULD be located on top of the IP on the network devices. Alternatively, SCA MAY be located between the IP and data link layer. In both cases, all the TCP packets MUST pass through the SCA.
In order to recognize TCP connection establishment/release requests and TCP data/ACK packets, SCA MUST access and read the content of the TCP header. Thus, SCA SHOULD NOT be used on network devices if TCP headers can not be read. SCA SHOULD NOT access and read TCP payload.
+-------------+ +-------------+
| | | |
| Application |<-------------End-to-End-------------->| Application |
| | | |
+-------------+ +-------------+
| |<-------------End-to-End-------------->| |
| TCP | +-------------+ +-------------+ | TCP |
| | | SCAP |<->| SCAP | | |
+-------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
| IP |<->| IP |<->| IP |<->| IP |
| | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+
TCP SCAP Device SCAP Device TCP
End Host (PEP) (PEP) End Host
Network devices MAY access TCP headers to work as middleboxes (i.e., performance-enhancing proxies (PEPs), firewalls, or NATs) [RFC6182]. As a kind of middlebox, SCAP devices function as PEPs that split and combine TCP traffic while preserving TCP end-to-end semantics (Figure 2).
SCAPs MUST work without any support from TCP end hosts. Neither TCP sender nor TCP receiver MUST be aware of the presence of any SCAPs. Thus, TCP end-hosts SHALL NOT be configured to find SCAPs. Instead, SCAPs SHOULD find other SCAPs to collaborate with.
SCA includes the following components to solve TCP problems [ref-ayar12] when multiple pipes are used:
Packet Classifier is responsible for looking at the TCP header to determine the packet type. An admission control policy MAY be applied to packets (Section 3.6) before accepting them into the SCAP. The packets that are not admitted MUST be passed to the lower/upper layer without SCAP processing.
SCAP-accepted TCP packets MUST be passed to the related SCA component:
Connection Handler manages the records of the TCP connections. TCP connection establishment procedure is followed to detect the TCP connections. TCP connection requests are detected by means of TCP segments with SYN flag.
TCP connection records MUST contain a unique connection identifier (tcp_conn_id) that is generated based on the TCP sender and receiver end-points (i.e., sender and receiver IP addresses and port numbers).
When TCP connection release packets (i.e., packets with the FIN or RST flag set) are received, the TCP connection release procedure is followed. When the connection tear-down is complete, all the connection related records MUST be deleted.
MPTCP uses IP addresses of the end-hosts in the subflow end-points. Similarly, SCAPs SHOULD use IP address pairs of SCAP devices as pipes. In that case, the peer MUST be informed about the used addresses, as MPTCP informs its peer by means of ADD_ADDR option.
TCP packets MAY be sent over these pipes to the SCAP peer by means of:
Since different methods may be used to send/receive data via SCA pipes, Multiple Pipes Adapter is defined as a component that interacts via specified APIs with other components of the SCA and handles interaction with IP.
Multiple Pipes Adapter interacts with IP to access and use the available pipes. Other SCA components use the Multiple Pipes Adapter APIs to get information about the pipes that may be used and to send data via them.
Multiple Pipes Adapter provides following APIs to the SCA components:
Data/ACK Processor is responsible for handling data/ACK packets. It shapes TCP traffic and decides on the scheduling of packets to the pipes.
Data/ACK Processor may apply to a TCP data/ACK packet one of the following operations (called 4-D) [ref-ayar12]:
SCAPs on different SCAP devices MAY exchange signaling information by means of the following methods:
Details of the signaling mechanism are out-of-scope of this document.
Configuration and Management Unit is used to set parameters for the SCA components. The configuration parameters may be defined for each component:
SCAPs may work in three modes:
+-----------+ +-----------+
| | | |
|Application|<---------------End-to-End-------------->|Application|
| | | |
+-----------+ +-----------+
| |<---------------End-to-End-------------->| |
| TCP | +--------+ | TCP |
| | | SCAP | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
| | | | | | | | | |
| IP |<->| IP |<->| IP |<->| IP |<->| IP |
| | | | | | | | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
TCP Network SCAP Network TCP
End Host Device Device Device End Host
As shown in Figure 3, SCA may still be used when there is only one SCAP on the path between the TCP end-hosts.
If there are multiple pipes from the SCAP to the TCP end-hosts, the SCAP may split and shape TCP traffic over them (e.g., [ref-ayar12a]). Since there is only one SCAP, it must work without any feedback via the signaling messages of the peer SCAP. Therefore, SCAP MUST NOT use signaling information during data transfer.
TCP end-hosts MUST NOT notice the existence of the SCAP. The TCP end-hosts will only see the effects of TCP traffic shaping.
As shown in Figure 2, SCAPs MAY work as a peer. The SCAP device peer may be located on the same access network as well as different access networks.
Section 1.3 discusses a scenario of SCAP devices located on different access networks.
Figure 4 shows two SCAP devices within the same access network. A TCP connection is established between an application on the single-homed Host A to an application on single-homed Host B.
In the data flow from Host A to Host B, SCAP-1 may split TCP packets via Pipe-1 and Pipe-2. This distribution may be used for load balancing purposes within the access network. In addition, if Pipe-1 and Pipe-2 are the bottleneck, then bandwidth aggregation of the pipes may be achieved. SCAP-2 combines the distributed packets, re-orders them and sends them in-order to the Internet. Similarly, for the data flow from Host B to Host A, SCAP-2 may split packets over Pipe-1 and Pipe-2 while SCAP-1 may combine them.
_____________________________ ____
| +---------------+ | ( )
+------+ | | Pipe-2 | | ( ) +------+
| | | +------+ +------+ | ( ) | |
| Host |---|-|SCAP-1|--------|SCAP-2|--|----( )---| Host |
| | | +------+ Pipe-1 +------+ | ( INTERNET ) | |
| A | | | ( ) | B |
| | | | ( ) | |
+------+ | Access Network | ( ) +------+
|___________________________| (____)
+-----------+ +-----------+
| | | |
|Application|<---------------End-to-End-------------->|Application|
| | | |
+-----------+ +-----------+
| |<---------------End-to-End-------------->| |
| TCP | +--------+ +--------+ +-------+ | TCP |
| | | SCAP |<->| SCAP |<->| SCAP | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
| | | | | | | | | |
| IP |<->| IP |<->| IP |<->| IP |<->| IP |
| | | | | | | | | |
+-----------+ +--------+ +--------+ +-------+ +-----------+
TCP SCAP SCAP SCAP TCP
End Host Device Device Device End Host
As shown in Figure 5, more than two SCAPs may be available on the path between the TCP end-hosts. In that case, SCAP peers constitute a SCAP chain. A SCAP distributes TCP packets over multiple pipes, and its peer combines them. This split/combine process is then repeated between each SCAP pair.
Since SCA is a thin layer underneath the TCP, it MAY also be placed on multi homed TCP end-hosts. SCA SHOULD be located in between the TCP and IP when it is used on the TCP end-hosts. Alternatively, SCA MAY be located between the IP and data link layer.
Figure 6 shows a SCAP peer on TCP end-hosts. SCA may be also used in the standalone setting (i.e., only on one TCP end-host).
Neither TCP nor IP SHOULD perceive the intervention of the SCAP:
In both cases, SCAP captures packets and processes them without TCP or IP having knowledge about that.
+-------------+ +-------------+
| Application |<-------------End-to-End-------------->| Application |
+-------------+ +-------------+
| TCP |<-------------End-to-End-------------->| TCP |
+-------------+ +-------------+
| SCAP |<------------SCAP-to-SCAP------------->| SCAP |
+-------------+ +-------------+ +-------------+ +-------------+
| IP |<->| IP |<->| IP |<->| IP |
+-------------+ +-------------+ +-------------+ +-------------+
TCP End Host Network Network TCP End Host
(SCAP Device) Device Device (SCAP Device)
+-------------+ +-------------+
| Application |<-------------End-to-End-------------->| Application |
+-------------+ +-------------+
| TCP |<-------------End-to-End-------------->| TCP |
+-------------+ +-------------+ +-------------+ +-------------+
| SCAP |<->| SCAP |<->| SCAP |<->| SCAP |
+-------------+ +-------------+ +-------------+ +-------------+
| IP |<->| IP |<->| IP |<->| IP |
+-------------+ +-------------+ +-------------+ +-------------+
TCP End Host SCAP SCAP TCP End Host
(SCAP Device) Device Device (SCAP Device)
Finally, in the most general case, SCAPs on TCP end-hosts MAY collaborate with the SCAPs on network devices as shown in Figure 7.
This draft includes no IANA considerations.
Will be added in a later version of this document.
| [1] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |