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 1823805418 2072152665
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. TCP IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community. 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.