With the advent of Software Defined Networks (SDN), Network Function Virtualisation (NFV) or Service Function Chaining (SFC), operators expect networks to support flexible services beyond the mere forwarding of packets. The network programmability framework which is being developed within the IETF by leveraging IPv6 Segment Routing enables the realisation of in-network functions.

Multipath TCP is a recent TCP extension that enables the utilization of different paths for a single connection. This provides various benefits including bandwidth aggregation and fast handovers on mobiles. A Multipath TCP connection starts with a single TCP connection called subflow and other subflows are added later to increase bandwidth or support failover. One drawback of Multipath TCP is that it is not currently compatible with stateless load balancers which rely on the five-tuple for their forwarding decision. This hinders the deployment of Multipath TCP. We show that this limitation can be circumvented with a small change to the handling of the initial subflow. Clients use this subflow to discover the load-balanced server and the additional Multipath TCP subflows are terminated at a unique address associated to each physical server. With this small change, Multipath TCP becomes compatible with existing stateless load balancers. Furthermore, we show that the same approach enables anycast Multipath TCP services, a major benefit given the difficulty of deploying anycast TCP services. We implement this modification in the Linux kernel and demonstrate its benefits with several micro benchmarks.

Datacenter networks provide high path diversity for traffic between machines. Load balancing traffic across these paths is important for both, latency- and throughput-sensitive applications. The standard load balancing techniques used today obliviously hash a flow to a random path. When long flows collide on the same path, this might lead to long lasting congestion while other paths could be underutilized, degrading performance of other flows as well. Recent proposals to address this shortcoming incur significant implementation complexity at the host that would actually slow down short flows (MPTCP), depend on relatively slow centralized controllers for rerouting large congesting flows (Hedera), or require custom switch hardware, hindering near-term deployment (DeTail).