Mitigating reordering vulnerability of MPTCP with transparent proxies

Modern end-hosts are generally equipped with more than one network interfaces. IETF responded to proliferation of multi-homed end-hosts and proposed MPTCP to allow concurrent use of multiple interfaces in data transfers. Basically, MPTCP uses regular TCP flows (called as MPCTP subflows) to send/receive application data over multiple paths. This approach benefits from the strengths of TCP (e.g., its high deployment), but also suffers from its weaknesses (e.g., its vulnerability to reorderings). Scattering TCP data packets to multiple paths produces lots of reordered packets due to path delay differences. In that case, performance of MPTCP subflows decreases too much. Therefore, it is not possible to use per-packet load balancers on MPTCP subflow paths although there is a big potential to use them in current network architectures (e.g., they enable efficient utilization of network resources with low computational complexity and they decrease congestion occurences by shifting traffic to uncongested parts of networks). In this paper, we address this issue and make our previous transparent and light-weight TCP proxy proposal (ORTA, Outof-Order Robustness for TCP with Transparent ACK Intervention) MPTCP-aware. That is, ORTA now recognizes MPTCP subflows by observing the MPTCP options and makes them robust against reorderings as it made regular TCP flows. Our new proposal is called as ORTAM (ORTA with MPTCP support). ORTAM allows reorderings on MPTCP subflow paths so that access networks and/or Internet service providers (ISPs) are able to use per-packet load balancers without any concern about MPTCP performance degradation. ORTAM is implemented and tested in NS-2. In the simulation scenarios, MPTCP subflow path delays are selected to reflect real Internet path delay observations. Different levels of reorderings are generated on the MPTCP subflow paths and MPTCP performance is measured. As expected, MPTCP performance decreases sharply when regular TCP is used for MPTCP subflows and reorderings are generated on the subflow paths. On the other hand, ORTAM makes MPTCP subflows highly robust against reorderings. When ORTAM is used, MPTCP performance was unaffected by even high levels of reorderings on the MPTCP subflow paths. In addition, ORTAM supplies this reordering robustness with its transparency feature (i.e., it does not change TCP sender or receiver implementations) which makes it easy to deploy on access networks or edge ISPs.