Internet DRAFT - draft-deng-mptcp-proxy
draft-deng-mptcp-proxy
MPTCP Working Group L. Deng
INTERNET-DRAFT D. Liu
Intended Status: Informational T. Sun
Expires: May 25, 2014 China Mobile
M. Boucadair
France Telecom
G. Cauchie
Bouygues Telecom
Oct 24, 2014
Use-cases and Requirements for MPTCP Proxy in ISP Networks
draft-deng-mptcp-proxy-01
Abstract
This document presents the use-cases and identifies requirements for
ISP deployed MPTCP proxies for both Fixed and Mobile networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 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
<Deng, et al.> Expires May 25, 2015 [Page 1]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Use-cases for ISP MPTCP Proxy . . . . . . . . . . . . . . . . . 6
3.1 Boosting MPTCP Utilization for M-UEs and Multi-Interface
CPEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Resource Pooling from Multiple Networks . . . . . . . . . . 7
3.3 Multiple Connections and Seamless Handover between
Multiple Networks . . . . . . . . . . . . . . . . . . . . . 7
3.4 Assist MTPCP Connection Establishment . . . . . . . . . . . 8
4 Deployment Considerations . . . . . . . . . . . . . . . . . . . 8
4.1 On-path MPTCP Proxy . . . . . . . . . . . . . . . . . . . . 9
4.2 Off-Path Proxy . . . . . . . . . . . . . . . . . . . . . . . 9
5 Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . 10
5.1 MPTCP Proxy at the ISP IP Gateway . . . . . . . . . . . . . 10
5.2 On-Path MPTCP Proxy at the ISP Data Center . . . . . . . . . 11
5.3 On-Path MPTCP Proxy at SmallCell Gateway . . . . . . . . . . 11
5.4 MPTCP Proxy at CPE/CGN for Fixed Access Networks . . . . . . 11
6 Requirements for MPTCP Proxy . . . . . . . . . . . . . . . . . 12
6.1 Protocol Proxying between MPTCP and TCP . . . . . . . . . . 12
6.2 Explicit Traffic Steering for Off-Path Proxying . . . . . . 12
6.3 Flexible Resource Policy within a Single ISP . . . . . . . 13
6.4 Protection against third-party traffic . . . . . . . . . . . 13
6.5 MPTCP Proxy Selection from Multiple Candidates . . . . . . . 14
6.6 Load Balancing Algorithm for Multiple Networks . . . . . . . 14
6.7 Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
9 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 Normative References . . . . . . . . . . . . . . . . . . . 17
10.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
<Deng, et al.> Expires May 25, 2015 [Page 2]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
1 Introduction
Internet Service Providers (ISPs) are challenged by the data
explosion occurring in their Fixed and/or Mobile networks. This data
explosion is triggered by new usages with the advent for resource-
demanding services. The emergence of these services is facilitated by
the emergence of new access technologies (FTTx in the Fixed or LTE in
the Mobile networks). Typical resource-demanding services are (HD)
video streaming or catchup IP-TV which are boosting more and more
every day the customers appetite for more IP bandwidth.
This pressure on continuous increase of network capacity poses a
challenge on the ISPs to appropriately plan, dimension and
dynamically provision their networks to satisfy customers
expectations. This problem is encountered by both Fixed and Mobile
Providers that have to cope with the scarcity of the radio frequency
resources, the limits of the already widely deployed DSL
infrastructure, or any in-place access technology.
The traditional trend that consist in upgrading the access technology
to a new generation technology may show some limits because of the
required upgrade cycles. Alternate deployment options to satisfy
customers' expectations and react rapidly to competition are of
interest of ISPs. A promising track, discussed in this document, is
to aggregate several connectivity links while eliminating risks to
experience application failures.
Indeed, a direction to answer to this problem is to make use of the
multiple interfaces that one terminal host maintains. For smartphones
or mobile dongles, these interfaces are typically a 3G/4G radio
access and a WLAN access, while for a residential CPE these
interfaces are typically a DSL line and a 3G/4G radio access.
3GPP initiated an effort to aggregate several radio resources for the
sake of increasing bit-rates (denoted as Carrier Aggregation (CA)).
Aggregation is achieved at the radio level by combining the set of
allocated contiguous or non-contiguous component carriers. This
extension requires modification at the radio interface level of the
UE (User Equipment), as well as some tuning on the network side.
Carrier Aggregation is specific to radio-based environments and, as
such, it is not convenient for other deployment cases, such as wired
networks.
Both 3GPP and IETF standard bodies have investigated different
solutions to make the best interface used for one application, with
potential use of multiple interfaces at the same time by
multitasking-enable terminals. As of today, none of them really did
meet a wide deployment and successful adoption.
<Deng, et al.> Expires May 25, 2015 [Page 3]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
The IETF released MPTCP specification [RFC6824], an experimental set
of TCP options allowing the use of parallel TCP connections, each
with different set of IP addresses and/or port numbers, to serve at
least one application. MPTCP is already available on some widely
adopted mobile handsets and on some Linux implementations. However,
MPTCP connections are pretty rare since the servers hosting the
applications are too few to offer MPTCP capability.
Because resources are scarce at the access segment, a solution to
enhance the quality of experience is to enable MPTCP at the access
segment without requiring MPTCP support at the server side (i.e., the
end-to-end MPTCP support is not required). Concretely, this can be
implemented owing to the deployment a dedicated function called MPTCP
Proxy at the ISP network side and/or in the CPE device. Note that
enabling an MPTCP Proxy in the CPE has the advantage to not require
MPTCP stack at the terminal side.
By this mean, an ISP can offer a higher bandwidth to its customers
when possible while not waiting for massive MPTCP adoption by the
Internet ecosystem. Furthermore, this technique would allow the ISP
and the customer to control the parts of the networks where potential
QoE degradation may be experienced and where the traffic can be
handled appropriately by means of traffic engineering tweaking for
instance. Since MPTCP requires a load-sharing algorithm to schedule
the TCP subflow to which the traffic is forwarded, the selection of
the proper algorithm could help for instance to offload the IP
traffic towards the legacy Fixed networks while taking advantage of
the complementary bandwidth only when needed/selected by the
customers, application, or the ISP.
Note that the use of MPTCP at customer side can be of different
natures as defined in MTPCP base specification:
o Native MPTCP: Two MPTCP endpoints establish and make use of all
subflows that correspond to the available addresses/port numbers.
This mode is enabled to optimize data throughput.
o Active/Backup MPTCP: Two MPTCP endpoints enable multiple
subflows, but only a subset of these subflows is actually in use for
data transfer. MPTCP endpoints can use the MP_PRIO signal to change
the priority for each subflow.
o Single subflow MPTCP: Two MPTCP endpoints use one single subflow
and when a failure is observed, an additional subflow is enabled so
that traffic is forwarded along the newly established subflow.
Based on the basic capabilities of an MPTCP-enabled host, various
deployment use cases can be considered by an ISP. Examples of such
<Deng, et al.> Expires May 25, 2015 [Page 4]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
use cases include: traffic handover among multiple WLAN hotspots,
traffic offload from a mobile network to WLAN or vice visa, and
access link aggregation.
In general, two flavors of MPTCP Proxy can be envisaged , see Figure
1:
o A MPTCP Proxy that maps a UE originated TCP connection into an
MPTCP connection. An example would be an MPTCP-enabled CPE, which
makes use of its own multiple local interfaces to maximize the
experience of bandwidth consuming applications for Non-MPTCP UEs.
o A MPTCP Proxy that maps an UE originated MPTCP connection into a
TCP connection. This is the case for most mobile terminals with
multiple interfaces and built-in MPTCP capability.
+----+ +------------+ +------------+ +------+
|Host| <=TCP=>| MPTCP Proxy|<=MPTCP=>| MPTCP Proxy|<=TCP=>|Server|
+----+ +------------+ +------------+ +------+
+----+ +------------+ +------+
|Host|<=MPTCP=>| MPTCP Proxy|<=TCP=>|Server|
+----+ +------------+ +------+
Figure 1: MPTCP Behaviors.
This documents details these use-cases and derived requirements for
MPTCP proxy deployment in ISP networks.
The use cases discussed in this document can also be valid for
Enterprise networks.
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].
This document makes use of the following terms: (For definitions of
other terms such as "(MPTCP) Connection", "Host" and "Subflow", refer
to [RFC6824].)
M-session: a MPTCP connection between a M-UE and a M-Server.
M-Server: a server with MPTCP capability enabled for the current TCP
<Deng, et al.> Expires May 25, 2015 [Page 5]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
session, or simply a serving MPTCP host. M-Server may be connected
to the network using one or multiple network interfaces.
M-UE: a user equipment with MPTCP capability enabled for the current
TCP session, or simply a requesting MPTCP host. Unless it is
explicated, an M-UE can be a host or a CPE.
N-Server: a server without MPTCP capability enabled for the current
TCP session.
N-UE: a user equipment without MP-TCP capability enabled for the
current TCP session.
MPTCP Proxy: proxy located between a M-UE and a N-Server, which
enables a M-session with the M-UE and maps it into a legacy TCP
connection with the N-Server.
Natural Path: a "natural path" of a subflow is the original path it
would traverse end-to-end if there is no explicit traffic steering
function is enabled for MPTCP Proxy.
Small Cell: generally refers to the cells with less than 1 watt
output power, e.g. picocell, femtocell, etc.
Nanocell: a type of base station integrated with both a small cell
and a WLAN access point.
3 Use-cases for ISP MPTCP Proxy
3.1 Boosting MPTCP Utilization for M-UEs and Multi-Interface CPEs
On the one hand, user equipment (esp. mobile terminals) nowadays have
multiple interfaces and could benefit from these interfaces if they
were using MPTCP.
On the other hand, servers often only support regular TCP and
upgrading them to support MPTCP will take more time than on the
clients.
Therefore, it is expected that an ISP deployed MPTCP Proxy would
benefit the M-UEs with better user-experience for almost all the
legacy applications by exploiting MPTCP capability at least for the
most resource-limited channel on the air, without relying on
pervasive MPTCP deployment at the server side.
The same approach can be followed for CPE-based deployment models.
These models can be refreshed to integrate CPEs that are able to
<Deng, et al.> Expires May 25, 2015 [Page 6]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
mount multiple interfaces.
3.2 Resource Pooling from Multiple Networks
For an ISP providing multiple access networks to its subscribers, a
locally deployed MPTCP Proxy would enable use-cases where the M-
UE/ISP is trying to pool access network resources from multiple
networks concurrently, e.g., among multiple WLAN hotspots, a fixed
and a WLAN connection, a cellular and a WLAN, a cellular and a Fixed
access, etc.
However, the specific pooling strategy can differ for various
scenarios, depending on the type of subscriber and the current status
of different networks, etc.
For example, from the user's perspective, business customers would
have perfect pooling while other users would get the cheaper network
whenever possible.
On the other hand, from the ISP's perspective, it would encourage
more efficient usage of network resource by dynamic charging policy
for rush hours, has a static preference for a specific network over
another one, or even desires traffic offloading to proactively
migrate less sensitive or more demanding traffic between multiple
networks it controls.
Criteria to invoke an MPTCP Proxy in a communication paths will be
the results of these policies (i.e., subscribers, applications, and
ISPs).
3.3 Multiple Connections and Seamless Handover between Multiple Networks
For cellular ISPs, the radio access networks are the dominating part
of their network construction investment. With the rapid development
of cellular technology and the imbalance of subscriber/traffic
distribution geographically, it is common practice to deploy leading-
edge technology in traffic boosting hot spots (e.g., downtown areas
in big cities) first while enabling seamless handover for legacy
cellular/wireless networks to guarantee service continuity for a
moving terminal.
A device can discover multiple networks, including multiple
attachment points to the same ISPs. This is the typical example of a
device that can be serviced with multiple WLAN hotspots. Instead of
selecting only one attachment point, the device can select multiple
ones when more resources are required. Maintaining simultaneous
attachment to these attachment points will also allow for seamless
handover and, therefore, allow for session continuity.
<Deng, et al.> Expires May 25, 2015 [Page 7]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
Implementing this feature may require an explicit signal to the
connecting device to drive its network attachment procedure. It is
out of scope of this document to discuss such signals nor elaborate
on potential impact on battery consumption on mobile devices mounting
multiple interfaces in parallel.
3.4 Assist MTPCP Connection Establishment
The MPTCP Proxy does not know in advance whether a remote server is
MPTCP-enabled. As such, the MPTCP Proxy can be provided with various
policies such as (but not limited to):
o TAKE-OVER Mode: Strip any MPTCP signal systematically in all TCP
messages to a remote server: This mode might be useful for two
scenarios: For the scenario where servers are not widely MPTCP-
enabled, it has the advantage to not suffer from MPTCP fallback delay
when the remote server is not MPTCP-enabled. For the scenario where
the ISP would like to limit the MPTCP traffic to its local network to
avoid unexpected blocking by third-party middle-boxes.
o TRANSPARENT Mode: Allow MPTCP signals to be passed to
systematically to remote servers: This mode has the advantage to
optimize MPTCP Proxy resources and favor direct communications
between an MPTCP-enabled UE and an MTPCP-enabled server without
invoking the MPTCP Proxy when both the server and client are MPTCP-
enabled.
o HYBRID Mode: The combination of the above two modes, according to
the proxy's local policy.
4 Deployment Considerations
For an MPTCP Proxy to correctly manage an M-session with the M-UE, it
is necessary for it to receive each subflow coming from the M-UE and
heading for the N-Server it is acting on behalf of. It is hence
straightforward to consider an on-path deployment strategy, where the
MPTCP Proxy is directly located on the common link of every subflow
from the M-UE.
However, for other cases where a common link is absent within the
local ISP's domain or resource pooling is desired from networks of
different ISP domains, the MPTCP Proxy has to steer off-path subflow
to traverse the selected MPTCP Proxy explicitly. Note that steering
functions should work for both directions over all the subflows, i.e.
including both uplink and downlink traffic from/to the M-UE.
Therefore, two types of MPTCP Proxy are considered in this document:
on-path MPTCP Proxy and off-path MPTCP Proxy.
<Deng, et al.> Expires May 25, 2015 [Page 8]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
4.1 On-path MPTCP Proxy
For different access networks provided by a single ISP, it is fairly
easy to locate a common link and deploy an on-path MPTCP Proxy
accordingly.
As depicted in Figure 2, the on-path MPTCP Proxy is located on each
potential path from a M-UE for both MPTCP traffic and legacy TCP
traffic.
( )
( Access Net #1 )
+--->(e.g. Cellular Network)<--+
+----+ | ....>( )<. | +-------+ +--------+
| |<--+ . ( ) . +->| |<==>| |
| |<..... ......>|On-Path|<..>| |
|M-UE| +----->| MPTCP | |N-Server|
| |<----+ | ....>| Proxy |<..>| |
| |<... | ( ) | . +-------+ +--------+
+----+ . +--->( Access Net #2 )<+ .
....>( e.g. WLAN Network )<.
( )
( )
-----subflow of an M-session
.....legacy TCP flow
=====merged TCP flow for an M-session
Figure 2. The On-Path MPTCP Proxy
4.2 Off-Path Proxy
On the one hand, it is not viable to assume for instance a common
link from a cellular ISP to deploy an on-path proxy on each potential
MPTCP subflow originating from its M-UE via third-party WLAN networks
for instance.
On the other hand, even for resource pooling from a single ISP's own
WLAN networks, it is not always feasible to find such a common link
for on-path MPTCP Proxy before corresponding traffic hitting the
public Internet.
( )
<Deng, et al.> Expires May 25, 2015 [Page 9]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
( Access Net #1 )
+--->(e.g. Cellular Network)<--+
+----+ | ....>( )<. | +--------+ +--------+
| |<--+ . ( ) . +->|off-Path|<==>| |
| |<..... ......>| MPTCP |<..>| |
|M-UE| ******>| Proxy | |N-Server|
| |<***** * +--------+ | |
| |<... * ( ) * ..................>| |
+----+ . *****>( Access Net #2 )<* . +--------+
....>( e.g WLAN Network )<.
( )
( )
-----subflow following its natural path
*****explicitly redirected subflow
.....legacy TCP flow
=====merged TCP flow for a M-session
Figure 3. The Off-Path MPTCP Proxy
As depicted in Figure 3, the off-path MPTCP Proxy is located on the
"natural path" of only a partial subset of potential subflow of a
given M-session, and relies on extra mechanism to explicitly steering
other subflows to deviate from their "natural path" and go through
it.
5 Deployment Scenarios
5.1 MPTCP Proxy at the ISP IP Gateway
For Fixed networks, MPTCP Proxy can be located in various segments
with a network (e.g., co-located with a CGN [RFC6888], a DS-Lite AFTR
[RFC6333], or a NAT64 device [RFC6146] if already present in the
network, co-located with a TCP acceleration and optimizer if any,
etc.).
As the anchoring point for 3GPP mobile UE originated IP traffic
within the cellular network, the IP gateway of 3GPP network (e.g.,
GGSN (Gateway GPRS Support Node) or PDN Gateway (PGW) [RFC7066])
would be a natural spot for MPTCP Proxy deployment. It is also
possible for the gateway to reuse existing interfaces with other 3GPP
network elements for information/policy acquisition. Alternatively,
another location for MPTCP Proxy deployment would be the (s)Gi
Interface(i.e., between the GGSN/PGW and an external PDN (Packet
Domain Network)).
<Deng, et al.> Expires May 25, 2015 [Page 10]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
5.2 On-Path MPTCP Proxy at the ISP Data Center
It is common practice for local ISPs to build up local data center
facilities within its domain for large Internet content providers in
order to feed user's requests locally, resulting in both enhanced
user experience for cut-short end-to-end delay and reduced expenses
for unnecessary cross-ISP peering traffic.
It is believed that by deploying an on-path MPTCP Proxy at the
entrance of the ISP's local data center, it would help various
Internet Content Provider residing within the data center to gain
enhanced user-experience for local subscribers with M-UEs without the
need to upgrade their servers manually.
5.3 On-Path MPTCP Proxy at SmallCell Gateway
Some ISPs are deploying small cells (low-powered radio access nodes)
with both cellular and carrier WLAN access. Small cells is expected
to be a cost-effective and green way for cellular network deployment
for both home and enterprise subscribers. For instance, it can be
integrated with the home gateway for a broadband subscriber.
Figure 4 outlines the Nanocell system architecture.
( )
+--+ +-(Cellular)-+ +--------+ Cellular
| |-+ ( ) +-|Nanocell| +-( Core )---( )
|UE| |(local |-(IP Backhaul)+ (Internet)
| |-+ ( ) +-|Gateway)| +-( WLAN AC )---( )
+--+ +-( WLAN )-+ +--------+
( )
Figure 4. Nanocell System Architecture
As a combined access node for both cellular and WLAN traffic, small
cell Gateway represents a spot for an on-path MPTCP Proxy at the
network edge.
Note that by applying local breakout scheme, where the small cell
doing IP-layer forwarding itself rather than relying on other 3GPP
routing devices, it is expected that no extensions to existing 3GPP
specs are needed for its integration with an MPTCP Proxy.
5.4 MPTCP Proxy at CPE/CGN for Fixed Access Networks
A first deployment model assumes MPTCP Proxy is enabled in a CPE.
This proxy aims to offer MPTCP service to non-MPTCP hosts located
<Deng, et al.> Expires May 25, 2015 [Page 11]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
behind the CPE. This model can be deployed with or without an MPTCP
Proxy at the ISP's network.
In early deployment stages, this model is likely to require an MPTCP
Proxy be also deployed at the ISP's network side. This is mainly to
shorten delays induced by TCP fall back when the remote server is not
MPTCP compliant.
Hosts located behind the CPE are not aware of the activation of the
MPTCP at the CPE side. MPTCP can be used for both bandwidth
aggregation and also ensure session continuity during failure
events.
6 Requirements for MPTCP Proxy
This section identifies requirements derived from the above use-cases
for an ISP MPTCP Proxy.
6.1 Protocol Proxying between MPTCP and TCP
In the on-path MPTCP Proxy use-case, the proxy is assured to be
deployed on the path of each potential subflow of a given MPTCP
session from the M-UE to the N-Server.
To allow a MPCTP-enabled UE to make full use of the multiple
interfaces even if it is interacting with an N-server, the on-path
MPTCP Proxy MUST satisfy the following requirements.
(a) Compatibility: An on-path MPTCP Proxy supports detection of M-
UE/N-server combinations for further proxying while leaving M-UE/M-
server and N-UE/N-server sessions intact.
(b) Transparency: An on-path MPTCP Proxy supports negotiation with
and acting towards the M-UE like a M-server on behalf of N-Server,
while acting towards the N-Server like a N-UE on behalf of the M-UE.
6.2 Explicit Traffic Steering for Off-Path Proxying
As we discussed earlier in the off-path MPTCP Proxy use-case, it is
required that subflows whose "natural path" does not include the
MPTCP Proxy be redirected explicitly to go through the proxy.
(c) Explicit Traffic Steering: an off-path MPTCP Proxy that enables
resource pooling from third-party WLAN networks MUST support explicit
traffic steering, to allow all the subsequent subflow traffic go
through the exactly the same MPTCP Proxy used in the correspondent M-
session establishment for both directions (including uplink and
<Deng, et al.> Expires May 25, 2015 [Page 12]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
downlink traffic from/to the M-UE).
(d) Globally Routable Address: an off-path MPTCP Proxy that enables
resource pooling from the same ISP's networks SHOULD expose a
globally routable address to allow explicit steering of subsequent
subflow traffic after they hit the public Internet.
6.3 Flexible Resource Policy within a Single ISP
Different from the end-to-end MPTCP solution, ISP deployed MPTCP
Proxy is a potential point for centralized cross-network flow control
over service/RAT preference for a given subscriber's M-UEs, which is
considered to be essential for better operation and service provision
in 3GPP networks.
However, to enable such fine-grained resource pooling policy from the
network side, it is essential that the MPTCP proxy knows for each
subflow its specific Network Access Type information.
(e) Network Access Type Information: an MPTCP proxy SHOULD be able to
make use of a reliable information sharing/reporting mechanism to
acquire a subflow's Network Access Type information/update on a real-
time basis.
(f) Resource Policy: an MPTCP Proxy MUST support flexible control to
set limits to both the number of concurrent subflows running in a M-
session and the number of concurrent M-sessions from an M-UE/to an N-
Server, according to the type and/or identity of relevant subscriber
and/or application.
6.4 Protection against third-party traffic
Apart from the traditional private network deployment practice, an
off-path MPTCP proxy exposes itself as publicly accessible from any
third-party traffic, where traditional access authorization or
admission control mechanisms from 3GPP network would not work. It is
therefore envisioned that an off-path MPTCP Proxy open for third-
party WiFi resource pooling MUST support minimal protection/policy
against potentially malicious traffic from third-party network.
(g) Provision Negotiation: an MPTCP Proxy SHOULD support both
subscriber/M-session/subflow level resource reservation negotiation
with a M-UE.
(h) Origin Authentication: an off-path MPTCP Proxy MUST support
subflow authentication for traffic from an unauthorized third-party
WiFi, in order to serve subflows belong to its intended M-sessions
coming from authorized subscribers or NAT, while turning down others
<Deng, et al.> Expires May 25, 2015 [Page 13]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
with least overhead.
(i) Admission Control: an off-path MPTCP Proxy MUST support admission
control to set limits to both the number of concurrent subflows on a
given M-session and the number of concurrent M-sessions for a given
subscriber/application.
6.5 MPTCP Proxy Selection from Multiple Candidates
When multiple MPTCP Proxies exist on an end-to-end path from the M-UE
to the N-Server, a natural question arises that "which MPTCP Proxy
should be chosen and how". There may be different considerations
depending on the location and types of MPTCP Proxy involved in
addition to the expectation of the application.
For example, assume an ISP deploys on-path MPTCP Proxy at smallcell
Gateway as well as an off-path MPTCP Proxy at the IP gateway of its
cellular network. The following considerations may apply.
On one hand, a straightforward policy would be to choose the nearest
MPTCP Proxy to the M-UE, i.e. the on-path MPTCP Proxy at smallcell
gateway which would lead to more efficiency from less traffic
convergence pressure. Another policy would be to prefer the on-path
MPTCP Proxy to the off-path one, which would cause unnecessary
traffic roundabout.
However, on the other hand, if a M-session is established with the
on-path MPTCP Proxy at smallcell gateway and when the M-UE moves out
of the coverage of the cell, the connection will be broken.
Therefore, it is reasonable to choose off-path MPTCP Proxy for
applications with strict service continuity expectations, while favor
on-path MPTCP Proxy for bulk data transfer with application-level re-
connection mechanisms.
In summary, regarding the MPTCP Proxy selection from multiple
candidates, the following requirement apply.
(j) Flexible Selection: when multiple M-Proxies are deployed on the
end-to-end path for a M-session establishment within the domain a
single ISP, it SHOULD be possible for the ISP to enforce flexible
selection policy regarding which MPTCP Proxy to serve which M-
session, based on the MPTCP Proxy's location, the MPTCP Proxy's type
(on-path/off-path) in addition to the application's expectation.
6.6 Load Balancing Algorithm for Multiple Networks
When multiple networks are available to service a subscriber, the
traffic may be balanced among those available paths for the sake of
<Deng, et al.> Expires May 25, 2015 [Page 14]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
QoE. The logic for balancing the traffic among those multiple paths
can be driven by application needs, customer's preferences, and/or
ISP traffic engineering guidelines.
From a traffic engineering perspective, the ISP may enforce policies
that would optimize various parameters such as:
o Network resources usage as a whole.
o Optimized invocation of available MPTCP Proxies (i.e., MPTCP Proxy
selection).
o Optimized MPTCP Proxy local performances (e.g., avoid overload
phenomena).
o Enhanced QoE (including increase both upstream and downstream
throughputs)
In summary, regarding the load balancing algorithm for multiple
networks, the following requirement apply.
(k) The MPTCP Proxy SHOULD be configurable with the load balancing
ratio per each available path.
6.7 Misc
Below are listed some additional requirements:
o Including an MPTCP Proxy in the communication may be seen as a
single point of failure. Means to protect against such failures
should be enabled.
o If TCP flows handled by the MPTCP Proxy are sourced with the
external IP address(es) that belong to the MPTCP Proxy, all hosts
serviced by the same MPTCP Proxy will be seen with the same IP
address(es). Means to mitigate the side effects documented in
[RFC6269] SHOULD be enabled in such deployment case.
o The MPTCP Proxy SHOULD NOT alter non-MPTCP signals included in a
TCP segment.
o The MPTCP Proxy MUST NOT inject MPTCP signals if the TCP option
size is consumed.
o The MPTCP Proxy SHOULD NOT inject MPTCP signals if this leads to
local fragmentation. MTU tuning may be required to avoid
fragmentation. MPTCP Proxy SHOULD be configurable to enable/disable
this feature.
<Deng, et al.> Expires May 25, 2015 [Page 15]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
o The MPTCP Proxy MUST take proper measure to avoid errors caused by
careless MPTCP signal modification to segments with other TCP
options. For instance, TCP-AO (TCP Authentication Option) [RFC5925],
which includes TCP options in the MAC computation, when present, MUST
be the first processed by the MPTCP Proxy.
o The MPTCP Proxy SHOULD be easy to scale to cope with growing
demand.
7 Security Considerations
As an MPTCP Proxy is playing N-UE and M-Server at the same time, the
security considerations that concerns a TCP client and a MPTCP-
enabled server are applicable to a MPTCP Proxy in general [RFC6181].
Forcing the traffic to cross an MPTCP Proxy that would not be
involved if legacy routing and forwarding actions are enforced raises
some security concerns. In particular, inserting an illegitimate
MPTCP Proxy can be used to hijack connections. Traffic inspected by
third party MPTCP Proxy may be used as a vector to reveal privacy-
related information.
These security concerns can be mitigated if the MPTCP Proxy is
managed by the same ISP offering connectivity to a customer.
Otherwise, specific mechanisms to be used are expected to be an
integral part of an MPTCP Proxy design and out of scope of this
document.
8 IANA Considerations
There is no IANA action in this document.
9 Acknowledgement
The authors would like to thank Olivier Bonaventure, Jordan Melzer,
Preethi Natarajan, Marc Portoles, Chunshan Xiong, Alper Yegin, Zhen
Cao and Hui Deng for their valuable comments and input to this
document.
<Deng, et al.> Expires May 25, 2015 [Page 16]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
10 References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
10.2 Informative References
[RFC6181] M. Bagnulo, "Threat Analysis for TCP Extensions for
Multipath Operation", RFC 6181, March 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC6333, August 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, June
2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, June
2011.
[RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan,
"IPv6 for Third Generation Partnership Project (3GPP)
Cellular Hosts", RFC 7066, November 2013.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
<Deng, et al.> Expires May 25, 2015 [Page 17]
INTERNET DRAFT <MPTCP Proxy Usecases and Requirements> Oct 24, 2014
Authors' Addresses
Lingli Deng
China Mobile
Email: denglingli@chinamobile.com
Dapeng Liu
China Mobile
Email: liudapeng@chinamobile.com
Tao Sun
China Mobile
Email: suntao@chinamobile.com
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange.com
Gregory Cauchie
Bouygues Telecom
Email: GCAUCHIE@bouyguestelecom.fr
<Deng, et al.> Expires May 25, 2015 [Page 18]
