A content can be replicated in more than one node, in Information Centric Networks (ICNs). Thus, more than one path can be followed to reach the same content, and it is necessary to decide the interface(s) to be selected in every network node to forward content requests towards such multiple content containers. A multipath forwarding strategy defines how to perform this choice. In this paper we propose a general analytical model to evaluate the effect of multipath forwarding strategies on the performance of an ICN content delivery, whose congestion control follows a receiver driven, loss-based AIMD scheme. We use the model to understand the behavior of ICN multipath forwarding strategies proposed in the literature so far, and to devise and evaluate a novel strategy. The considered multipath forwarding strategies are also evaluated in a realistic network setting, by using the PlanetLab testbed.
- The exploitation of end-to-end multipath requires to discover remote NICs and to split data traffic among them. These operations, and congestion control, can be executed above the IP layer. Consequently, as shown in fig. , end-to-end multipath systems run above the IP network layer, at the communication end-points, without affecting network nodes. Usually, a multipath forwarding strategy splits traffic on a per-packet basis, to maximize the transfer rate. For instance, in the multi-homed'' scenario (fig. ) the MultiPath TCP (MPTCP) protocol @cite_12 sets up parallel subflows among couples of NICs discovered through TCP options, uses a TCP-friendly congestion control per-subflow, and schedules traffic on the different sub-flows according to a specific forwarding strategy @cite_8 @cite_14 . In the server pooling'' scenario, a receiver can use a BitTorrent approach to concurrently fetch different file pieces from different sources, discovered with Web means. The transfer of each piece is controlled by a TCP connection.
@cite_14 @cite_12 @cite_8
1515106148 2067655170 2072152665 2142480021
Multipath TCP, as proposed by the IETF working group mptcp, allows a single data stream to be split across multiple paths. This has obvious benefits for reliability, and it can also lead to more efficient use of networked resources. We describe the design of a multipath congestion control algorithm, we implement it in Linux, and we evaluate it for multihomed servers, data centers and mobile clients. We show that some 'obvious' solutions for multipath congestion control can be harmful, but that our algorithm improves throughput and fairness compared to single-path TCP. Our algorithmis a drop-in replacement for TCP, and we believe it is safe to deploy. This paper focuses on evaluating the use of MPTCP to forward sub flows in Open Flow networks. MPTCP is a network protocol designed to forward sub flows through disjointed paths. Modern networks commonly use Equal-Cost Multipath Protocol (ECMP) to split flows through distinct paths. However, even with ECMP enabled, sub flows may be forwarded through the same path. MPTCP improves the multipath routing by setting sub flows to be forwarded through distinct paths. As a consequence, the amount of sub flows must be considered to evaluate the network throughput. In this paper, we design Multiflow to use MPTCP in Open Flow networks. Our proposal is to improve the throughput in shared bottlenecks by forwarding sub flows from a same MPTCP connection through multiple paths. We validate our approach in a test bed where shared bottlenecks occur in the link at the endpoints. The Multiflow improvement of the network performance is evaluated in experiments about resilience and end-to-end throughput. Multipath transport protocols such as Multipath TCP can concurrently use several subflows to transmit a TCP flow over potentially different paths. Since more than one subflow is used, an efficient multipath scheduling algorithm is needed at the sender. The objective of the scheduler is to identify the subflow over which the current data packet should be sent. This paper compares the most important types of schedulers for multipath transfers. We model their performance analytically and derive key metrics, most notably the resulting end-to-end delay over heterogeneous paths. Our results show that a scheduler minimizing the packet delivery delay yields the best overall performance, but it is complex to realize. An alternative scheduler based on the sender queue size is simpler and has sufficient performance for relatively small asymmetry between the multiple paths. Our model results are confirmed by measurements with a real multipath transport protocol. The latest large-scale data centers offer higher aggregate bandwidth and robustness by creating multiple paths in the core of the net- work. To utilize this bandwidth requires different flows take different paths, which poses a challenge. In short, a single-path transport seems ill-suited to such networks. We propose using Multipath TCP as a replacement for TCP in such data centers, as it can effectively and seamlessly use available bandwidth, giving improved throughput and better fairness on many topologies. We investigate what causes these benefits, teasing apart the contribution of each of the mechanisms used by MPTCP. Using MPTCP lets us rethink data center networks, with a different mindset as to the relationship between transport protocols, rout- ing and topology. MPTCP enables topologies that single path TCP cannot utilize. As a proof-of-concept, we present a dual-homed variant of the FatTree topology. With MPTCP, this outperforms FatTree for a wide range of workloads, but costs the same. In existing data centers, MPTCP is readily deployable leveraging widely deployed technologies such as ECMP. We have run MPTCP on Amazon EC2 and found that it outperforms TCP by a factor of three when there is path diversity. But the biggest benefits will come when data centers are designed for multipath transports.