boosting cloud communications through a crosslayer...

Software Defined Networks for Future Networks and Services (SDN4FNS)

Boosting Cloud Communications through a Crosslayer Multipath Protocol Architecture

Matthieu Coudron, Stefano Secci, Guy PujolleLIP6, Université Pierre et Marie Curie

Guido Maier, Achille PattavinaDipartimento di Elettronica e Informazione, Politecnico di Milano

12 November 2013 – EIT ICT, Trento

[email protected], [email protected]

BONSAI LabBONSAI Lab

SND4FNS, Trento, Italy – 12 November 2013 22

Outline

IntroductionMultipath TCPGeneral architectureMPTCP + LISP + TRILL implementationEarly experimental resultsConcluding remarks

SND4FNS, Trento, Italy – 12 November 2013

Multipathing

Multipath communications represent a chance…– Multihoming practices at both server and user endpoints and network

levels – Path diversity for protection– Effective end-to-end load-balancing

… and a hassle for the current Internet– Internet protocols have been mainly designed with a single active path

paradigm

3


Aim of our work

Our goal is to resort to multipathing to improve Cloud access and inter-Cloud performance, more precisely– Increasing Cloud connection throughput– Decreasing transfer times and improving user Quality of Experience– Boosting storage consolidation and virtual machine migration

Multipathing increases Cloud availability guarantee via different techniques– External interconnection of data-centers (DCs) with multiple

independent provider links– Deployment of intra-DC multipath layer-2 protocols and IP endpoint

multihoming

4


Cloud networking reference scenario

Major challenges to address– How to send and receive data packets along different paths without

disturbing applications?– How to select disjoints paths in order to provide higher resiliency and to

avoid bottlenecks?– How to ensure packets really follow disjoint paths?

5

Data-center networks, with user-to-Cloud, intra-DC and inter-DC communications, 4 node types

– Virtualization Cloud servers, with MPTCP enabled at the hypervisor level

– Cloud users (potentially mobile), able to establish MPTCP connections even when single-homed

– Border nodes, i.e. routers at the DC/ISP and user/ISP borders

– Cloud Controllers, managing a DC network, for path discovery and establishment


Protocol coordination

Using different paths in a uncoordinated way, TCP performance can be decreased rather than increased– Packet arrival disorder triggers retransmissions that disturb the application

workflowSelecting Internet-wide end-to-end disjoint paths is unrealistic dream with common Internet-ecosystem routing and control protocols

In this paper, we tackle the challenge of establishing coordinated multipath communications in a Cloud environment composed of multihomed data-center networks and users– Simple functional blocks and protocol coordination mechanisms– Realistic assumptions and partially already available protocol functionalities– Protocol interoperability perspective, – Increasing throughput and resiliency within and across administration

domainsWe present both stateless and stateful solutions to end-to-end path diversity management, involving novel protocols

6


Multi-Path TCP

Multiple-Path TCP is a TCP extension– First acknowledges if destination is MPTCP compliant– Creates TCP subflows associated with a master TCP connection– Endhosts can advertise their IPs, add or remove MPTCP subflows at anytime– Joint congestion-control and protection technique

The round-trip-time (RTT) gap among subflows should be small– Packet disordering can be absorbed by TCP end-point buffering

7

1GB/s

1 IP 1 IP

100MB/s

100MB/s


Multi-Path TCP

Implementation of MPTCP at the hypervisor level – Scalable deployment– MPTCP agnostic virtual machines– Subflows differ with respect to their source or destination IP (if

multihomed), or via the subflow TCP port (in case one server is singlehomed)

Our proposition: protocol architecture that stitches MPTCP subflows to Ethernet- and IP-level paths, which are as much disjoint and RTT-similar as possible

8


Functional blocksAt the controller or hypervisory level

Flow Qualification Service: – Identify which connection benefits from a multipath communication– Distinguish «elephant» flows (i.e., long-lived) from «mice» (i.e., short-lived)

Flow Monitoring Service– Update the multipath configuration– Allow virtually compensating RTT variations with artificial delays at the

hypervisor software levelPath Discovery Service– Traffic Engineering Database (TED) service– Collect information about the available path diversity– To be decomposed into an Intradomain Discovery Service (i.e., a controlled

network scope, such as a DC network), and an Interdomain Discovery ServicePath Computation Service– Select paths to assign to flows when requested– Take into account constraints specified in the request

9


Functional blocksAt the controller or hypervisory level

Path Enforcement Service– Packets have to use the selected paths– Stateful and stateless modes possible

• Stateful signaling: network path setup on per flow basis, e.g., using Software Defined Networking (SDN) or MPLS-based architectures

• Stateful explicit forwarding: the source (i.e., the Cloud server’s hypervisor, actively or passively via the Controller) lists in each packet the nodes the packet must pass through

• Stateless forwarding: the source exploits network load-balancing algorithms and crafts packets’ headers so that they follow foreseen paths

10


Multipath Signaling

Stateful mode: intra-DC paths are virtually stitched with MPTCP subflowsby the hypervisor, and at border nodes inter-DC (loose) paths are stitched with intra-DC pathsStateless mode: the hypervisor is informed about load-balancers and available path diversity at intra-DC and/or inter-DC segmentsEvents such as node/link congestions/failures/additions could trigger hypervisors, causing subflow deletion or addition, or new path computation and enforcement

11

In case the endpoint B is a user terminal, there is no need for path stitching at site B


MPTPC + LISP + TRILL implementation

At each Cloud network segment interoperability between protocols is needed to propagate path diversity across segments– One solution: SDN (OpenFlow) as ubiquitously as possible – A reasonable alternative: rely on three new distributed protocols recently

defined to handling path diversity at each segment, with an adequate coordination

Besides MPTCP:– LISP handles path diversity at the extra-DC segment between border nodes– TRILL enable multipath Ethernet-layer communications within the DC

Both LISP and TRILL are– Incrementally deployable in the existing Internet infrastructure– Address all the previously described use-cases– Allow supporting path diversity across layers in a scalable and practical way– None of them fully standardized, yet they have all been implemented to some

degree

12


MPTPC + LISP + TRILL implementation

13

Another common feature: all protocols are mapping one upper layer logical point to many lower-layer logical points– MPTCP one application port to many IP interfaces– LIPS one IP address to many IP routing locators– TRILL one MAC address to many Ethernet routing locators

MPTCP TRILL LISP

Cloud controller:NMS

or SDNor PCE


MPTCP + LISP integrationFirst experimental results

14

French inter-DC testbed NuageLISP and MPTCP integration

– Results being presented at CloudNet 2013


Concluding remarks

Multipathed communications is an open networking research field– Coordination necessary between network layers and protocols

The architecture we propose in this paper unifies the different control planes thanks to coordinated routing mechanismsCoordination between the MPTCP, TRILL and LISP protocols, splitting flows at the transport, network and Ethernet layers,– can allow carefully selecting communication paths, – while controlling the computational load, – and guaranteeing a semi-distributed reliable communication environment

15

boosting cloud communications through a crosslayer...

Documents