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

Abstract

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.

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 August 02, 2012.

Copyright Notice

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.


Table of Contents

1. Introduction

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.

1.1. Requirements Language

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.2. Terminology

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.

1.3. Reference Scenario

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)|   +------+
           +--------+        (______)        +--------+
               

2. SCA Design

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.

2.1. SCA Protocol-Stack Transparency

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).

2.2. SCA End-Point Transparency

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.

3. SCA Components

SCA includes the following components to solve TCP problems [ref-ayar12] when multiple pipes are used:

3.1. Packet Classifier

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:

3.2. Connection Handler

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.

3.3. Multiple Pipes Adapter

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:

  1. PIPE-ID-LIST find_pipes(tcp_conn_id, destination_address)

    is used to find pipes that may be used to send TCP data packets to the destination_address and returns the list of them, if any.

    tcp_conn_id is used to identify the connection that needs the pipes to be assigned. Multiple Pipes Adapter may access information about the connection (e.g., source/destination TCP end-point) by using the tcp_conn_id. The API also associates the list of pipes found with the connection.

    The PIPE-ID-LIST contains pipe_ids which are assigned by the Multiple Pipes Adapter to the available pipes (i.e., each pipe has a unique pipe_id).



    Pipe implementation is shielded from the other components by means of pipe_ids: other components only know pipe_ids and Multiple Pipe Adapter handles pipes.
  2. PIPE-PROPERTIES get_pipe_properties(tcp_conn_id, pipe_id)

    is used to probe for characteristics of a pipe.

    PIPE-PROPERTIES includes the required pipe parameters by the SCA instance (e.g., bandwidth, delay, utilization, packet loss rate, etc.).

    In order to get pipe parameters, following methods may be used [ref-ayar12]: packet-pair based estimation of the pipe delays and capacities, tracking the TCP timestamps [RFC1323], SACK [RFC2018] or D-SACK [RFC2883] to estimate packet arrivals at the receiver, or probing pipe capacities with TCP-like cwnd increase and decrease [RFC6356].

    In addition, the local MIB information (e.g., [RFC2863] [RFC4022] [RFC4293] [RFC4898]) may be used to set the initial values just after the pipes are found by Multiple Pipes Adapter.

    If tcp_conn_id is NULL, then the total pipe characteristics are returned. Otherwise, tcp_conn_id is used to get pipe characteristics relevant to a TCP connection. For example, the bandwidth used by a TCP connection may be asked as well as the total bandwidth of the pipe.
  3. PIPE-ID-LIST employ_pipes(tcp_conn_id, pipe_id_list)

    is used by Multiple Pipes Adapter to associate pipes which become available after the connection establishment. For example, an interface becomes active or a host associates with an AP/router after the pipes were assigned to the TCP connection by use of the find_pipes() API.

    Pipes in the pipe_id_list are associated with the connection with tcp_conn_id.
  4. PIPE-ID-LIST withdraw_pipes(tcp_conn_id, pipe_id_list)

    is used when a connection terminates or connection doesn't need some pre-assigned pipes.

    Pipes in the pipe_id_list are disassociated from the connection with tcp_conn_id.



    It MUST be called after the connection termination and MAY be called during the connection to cancel the use of some pipes which are previously assigned to the connection.

    In addition, Multiple Pipes Adapter may use this API to disassociate some pipes which become unavailable during the connection. For example, an interface becomes inactive or a host looses its connection to an AP/router.
  5. PIPE-ID-LIST select_pipes(tcp_conn_id, pipe_id_list)

    is used to select a subset from a set of pipes based on a pipe selection policy (Section 3.6).

    tcp_conn_id is used to determine the pipe selection policy for the connection. The API uses withdraw_pipes() API to disassociate filtered pipes by the pipe selection policy and returns back the remaining pipes.
  6. send_mp_packet(tcp_packet, tcp_conn_id, pipe_id)

    is used to send a packet via one of the multiple pipes.

    Since other SCA components only know the pipe_ids and do not know what the real pipes are, they use this API to send a tcp_packet which belongs to the connection with tcp_conn_id by using the the pipe with pipe_id.

    tcp_conn_id is supplied to enable update for pipe characteristics related with the TCP connections. For example, if a pipe is assigned to more than one TCP connection, what proportion of the pipe is used by the assigned TCP connections.
  7. TCP-PACKET check_encapsulation(tcp_packet)

    is used to check whether tcp_packet is encapsulated or not.

    Packets may be sent/received encapsulated. Since other components are shielded from the use of encapsulation, only the Multiple Pipes Adapter knows about the encapsulation.

    send_mp_packet() API encapsulates packets before sending them when encapsulation is necessary.

    When packets are received by the Packet Classifier, it uses check_encapsulation() to get decapsulated packets, if encapsulation is used for the connection. It returns the packet immediately if encapsulation is not used.

3.4. Data/ACK Processor

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]:

  1. duplicate: TCP packets may be (one or more times) duplicated and scheduled to multiple pipes to create robustness against packet losses.
  2. delay: TCP packets may be buffered and delivered later, based on a timer or a condition. For example, some packets of a TCP flow may be intentionally delayed to shape the TCP traffic (e.g., to reduce number of out-of-order packet arrivals at the receiver side, or to separate sent packets by a given interval). Another example is to buffer and reorder out-of-order packets before they are passed to the TCP receiver.
  3. deliver: TCP packets may be released immediately after their capture, or after the delay or duplicate operation. Delivery may be done locally for the incoming packets or over any available pipe to outgoing packets. For outgoing packets, one of the available pipes must be selected to efficiently utilize the pipes.
  4. drop: TCP packets may be dropped by SCAP. For example, assume that a packet is buffered for early retransmission purposes. If the ACK for that packet arrived and the buffered packet is not needed to be kept any more, it may be dropped.

3.5. Signaling Unit

SCAPs on different SCAP devices MAY exchange signaling information by means of the following methods:

  1. in-band signaling, by means of TCP options as in MPTCP. The SCAP that wants to send a signaling information will generate an SCA option and add it to the TCP packet. The peer SCAP will use the content of the SCA control option and remove it from the packet.

    The main drawback of the in-band signaling is that its size is limited by the TCP option space allowed. 16-21 bytes of space is left for the SCA options when the most common TCP options are encountered [I-D.ietf-mptcp-multiaddressed].
  2. out-of-band signaling that may use signaling channels established between the SCAPs.

    SCAPs may use a well-known port number to exchange signaling packets (e.g, RIP routing processes use UDP port 520 [RFC2453] or BGP systems use TCP port 179 [RFC1771]).

  3. hybrid signaling that may use in-band signaling to carry out-of-band signaling channel end-point information between SCAPs. First a connection between the signaling channel end-points will be established. Then, out-of-band signaling over the connection may be used to exchange the signaling data.

Details of the signaling mechanism are out-of-scope of this document.

3.6. Configuration and Management Unit

Configuration and Management Unit is used to set parameters for the SCA components. The configuration parameters may be defined for each component:

4. SCA Deployment Scenarios

SCAPs may work in three modes:

  1. Standalone SCAP: If there is only one SCAP on the path between the TCP sender and the receiver, SCAP must work alone
  2. SCAP Pair: If there are two SCAPs on the path, then they may work as a peer
  3. SCAP Chain: If there are multiple SCAPs on the path, then they may be used as cascaded chains

4.1. Standalone SCAP

+-----------+                                         +-----------+
|           |                                         |           |
|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.

4.2. SCAP Peer

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       |      (      )     +------+
           |___________________________|       (____)
               

4.3. SCAP Chain

+-----------+                                         +-----------+
|           |                                         |           |
|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.

5. SCA Extensions

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.

6. IANA Considerations

This draft includes no IANA considerations.

7. Security Considerations

Will be added in a later version of this document.

8. References

8.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[3] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[4] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[5] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[6] Malkin, G.S., "RIP Version 2", STD 56, RFC 2453, November 1998.
[7] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[8] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[9] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[10] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[11] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[12] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[13] Mathis, M., Heffner, J. and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[14] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[15] Raiciu, C., Handley, M. and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011.
[16] Ford, A, Raiciu, C, Handley, M and O Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", Internet-Draft draft-ietf-mptcp-multiaddressed-06, January 2012.
[17] Scharf, M and A Ford, "MPTCP Application Interface Considerations", Internet-Draft draft-ietf-mptcp-api-03, November 2011.
[18] Ayar, T.A., Rathke, B.R., Budzisz, L.B. and A.W. Wolisz, "A Splitter/Combiner Architecture for TCP over Multiple Paths ", TKN Technical Report Series TKN-12-001, February 2012.
[19] Ayar, T.A., Rathke, B.R., Budzisz, L.B. and A.W. Wolisz, "TCP over Multiple Paths Revisited: Towards Transparent Proxy Solutions ", Accepted by The IEEE International Conference on Communications 2012 (IEEE ICC'12), June 2012.

Authors' Addresses

Tacettin Ayar Technical University Berlin Telecommunication Networks Group, Sekr. FT5, Einsteinufer 25, Berlin, 10587 Germany Phone: +49 30 314 28225 EMail: ayar@tkn.tu-berlin.de
Berthold Rathke Technical University Berlin Telecommunication Networks Group, Sekr. FT5, Einsteinufer 25, Berlin, 10587 Germany Phone: +49 30 314 23832 EMail: rathke@tkn.tu-berlin.de
Lukasz Budzisz Technical University Berlin Telecommunication Networks Group, Sekr. FT5, Einsteinufer 25, Berlin, 10587 Germany Phone: +49 30 314 23836 EMail: budzisz@tkn.tu-berlin.de
Adam Wolisz Technical University Berlin Telecommunication Networks Group, Sekr. FT5, Einsteinufer 25, Berlin, 10587 Germany Phone: +49 30 314 22911 EMail: awo@ieee.org