Subject: Re: [multipathtcp] Request comments ondraft-xue-mptcp-tmpp-unware-hosts-00

From: kpxue <[email-masked]>
Date: Mon, 9 Jul 2012 23:25:59 -0500

Hi all,

Please provide comments and feedback of our draft. 

According to whether end hosts run MPTCP, the case "Neither end host runs MPTCP" is metioned, which is hotly discussed in WG meeting(IETF-83) and mailist.

TMPP (Transparent MPTCP Proxy) is predominantly used when two MPTCP-unaware hosts are communicating with each other, and at least one of them is located in mobile access networks enabling mobile access gateways with MPTCP function towards network side, or one network element in the network supporting multipath. In other words, the connection split-point may locate in the access side or the operators' networks.

we think there are following deployment scenarios fitting into this case.

1) Split-point locates in the access networks. The access gateway provides MPTCP function towards network side, and the multipath connection begins and ends both at the seperate access gateways. While it's not realistic to make all end devises MPTCP-capable, keeping MPTCP function on network-side will be helpful by ensuring the network access devise is MPTCP-capable. 
(a)A household access device is connected to the Internet via multiple access methods, while the end devise via a unique way to the access devise.
(b)A vehicle network has several access methods, while the mobile devices hold by passengers can connect it via only one way (e.g. Wi-Fi).
In the this scenario, it simply solves the problem by providing a MPTCP-capable access gateway, then it only needs network edge devices'support, however, it costs much because the edge device should have several SP signings.
                               
              +--------+________________________+--------+
   +------+   |        | :          :         : |        |   +------+
   |      |   | Access |________________________|        |   |      |
   | Host |   | Gateway| :          :         : | Access |   | Host |
   |      |---|    A   |________________________|Gateway |---|      |
   |   A  |   |        | :          :         : |    B   |   |   B  |
   |      |   |        |________________________|        |   |      |
   +------+   | (TMPP) | :          :         : | (TMPP) |   +------+
              +--------+                        +--------+
                             Figure 1

2)Split-point locates in the operators' networks. Currently, the bottleneck is the access side's entrance into the core network. Although the inside core network works well, the low efficiency in backhaul limits the whole system's performance. The earlier for the multiple paths to aggregate, the better, which is the same to separate, so it’s suggested to put the split point into an operator network element. In this way,  
(a)it will be convenient for operator's flexible management and charging. 
(b)Since the multiple paths are managed by the operator, this single connection needs only one SP signing.
Two cases of this scenario:
2-1)The sender or the receiver is limited, the un-limited end host locates in Internet, and a MPTCP-capable P-GW manages multipath.
               +--------+_________________+--------+  
    +------+   |        | :          :    |        |           +--------+
    |      |   | Access |_________________|  MPTCP |           |        |
    | Host |   | Gateway| :          :    |-capable|           | Host   |   
    |      |---|        |_________________| P-GW   |-----------|  B     |  
    |   A  |   |        | :          :    |        |           |(locates|
    |      |   |        |_________________|        |           |   in   |
    +------+   | (TMPP) | :          :    |        |           |Internet|
               +--------+                 +--------+           +--------+  
                                      Figure2

2-2)Both the sender and the receiver are limited. and there are two MPTCP-capable P-GWs working for them separately.

              +--------+_________________+--------+      +--------+_________________+--------+
   +------+   |        | :          :    |        |      |        | :          :    |        |      +------+
   |      |   | Access |_________________|  MPTCP |      |  MPTCP |_________________| Access |      |      |
   | Host |   | Gateway| :          :    |-capable|      |-capable| :          :    | Gateway|      | Host |
   |      |---|   A    |_________________| P-GW A |------| P-GW B |_________________|   B    |------|      |
   |   A  |   |        | :          :    |        |      |        | :          :    |        |      |   B  |
   |      |   |        |_________________|        |      |        |_________________|        |      |      |
   +------+   | (TMPP) | :          :    |        |      |        | :          :    | (TMPP) |      +------+
              +--------+                 +--------+      +--------+                 +--------+
                                             Figure 3

Recently, [draft-ayar-transparent-sca-proxy-00] presents a new architecture, named SCA (Splitter/Combiner Architecture), which enables non-MPTCP-capable single-homed hosts to benefit from multipath by means of PEPs (Performance Enhancing Proxies) placed in the access networks. This draft corresponds to the this case, but it is controversial since it's completely independent of MPTCP architecture.

We think there are one simple thing to support this case. In order to provide chances for a connection between two MPTCP-unaware hosts to enjoy multipath support, we make a change which requires another implicit MPTCP network node should also insert MP_CAPABLE to the SYN-ACK response even if finding the PROXY flag set in the MP_CAPABLE option. 

------------------------
Kaiping Xue

---

From: kpxue <[email-masked]>
Date: Mon, 9 Jul 2012 23:42:55 -0500

Hi all,

Another thing for MPTCP Proxy is maintenace in TMPP. Take the first scenario which I described in the last email. The end-to-end connection is splitted into two TCP sections and one MPTCP section, the couples of TMPPs become the end points for all further subflows. 
These subflows may be initiated by TMPP, and to avoid being established with the MPTCP-unaware hosts, TMPPs must inform about their existence and IP addresses with each other. Like NAT, TMPP A assigns the received packets to subflows already established between TMPP A and TMPP B, then change IP head and TCP head. TMPP A maintains the translation relationship and inform this information to TMPP B.
With the reception of the packet from TMPP A, TMPP B acknowledges it at subflow level, sending ACK to TMPP 
A (the ACK number is at subflow level).
At the same time, TMPP B recovers the locators to those of host A, removes MPTCP option, and sends the packet to host B.
Host A and Host B can be unaware of MPTCP Processing.

Also another practical way is using tunnel. such as Figure2. If using this method, TMPP A does not need to inform the translation relationship to TMPP B, because TMPP B only need to remove the outside encapsulation.  

If it were feasible, we will futher design it in details as soon as possible.

                          Fingure 1

                  +---------+---------+---------+---------------------------------+
                  |   IP    |   TCP   |  MPTCP  | Received IP packet From host A  |
                  +---------+---------+---------+---------------------------------+
                                          Fingure 2

------------
Kaiping Xue