In recent years, end-users have increasingly become equipped with devices having a plurality of network interfaces. These interfaces use different technologies to access the Internet such as cellular networks or fixed access networks as well as wired or wireless local access networks. These technologies exhibit different quality characteristics in terms of coverage, capacity, power consumption, geographical availability and cost. At the same time, as more and more data intensive applications find their way onto the Internet, the demand for high data transfer rates is constantly rising. Thus, bandwidth management has become a critical issue.
Current Internet protocols, and in particular TCP/IP, were designed to avoid wasting precious resources and process all packets equally such that when a link is congested, packets are simply lost. Increasing network capacity is often not the right solution for solving the increasing needs of voluminous data transfers and multimedia applications. To improve the quality of service (QoS) of current networks, it is widely agreed that using more than two interfaces concurrently would generally increase the available bandwidth. But in many cases, a single interface might not be able to fulfill all the traffic requirements on its own. Concurrent multipath transfer can improve reliability for real time applications since data is divided and transferred over multiple paths and when a problem occurs on one path the other paths are not affected and the session is maintained alive.
Researchers address the problem of concurrently using multiple network interfaces from a number of different angles. Several multipath approaches have been proposed in all layers of the TCP/IP stack: physical, link, network, transport and application. Lower layer techniques allow more efficient use of a particular link type and present a generic solution for all upper layer protocols and applications. On the other hand, solutions on the upper layers are more tuned to the need for a specific application. A trivial approach consists of the application opening several parallel TCP connections and this approach enables load balancing on the same physical interface. Application layer multipath transmission introduces implementation difficulty by requiring application specific updates. The latest generation exploits the transport layer with solutions such as multipath TCP or SCTP (acronym for “Stream Control Transport Protocol”) with its' native multi-homing capability. The transport layer is the best level to manage concurrent multipath since it has precise knowledge about end-to-end network paths.
The Stream Control Transmission Protocol (SCTP) was designed from scratch to overcome some of TCP's limitations such as vulnerability to SYN attack, head-of-line blocking, and absence of support for multihoming. SCTP is a connection oriented protocol which provides reliable transport service messages for application users. An SCTP connection is called an association and an association contains multiple streams (multistreaming). Multihoming is an essential property of SCTP allowing an association to incorporate several source and destination addresses. Each node can be accessed by several addresses.
Multihoming is an essential feature of SCTP allowing an association to be associated with several source and destination addresses. Each node can be accessed by several addresses. Currently, standard SCTP uses the multihoming feature only for retransmission and fail over; other application of multihoming such as load balancing are not supported. There have been several works on load-balancing over the multiple paths in SCTP, exploiting simultaneous utilization of more than one of the available interfaces.
El Al et al, “Load Sharing in Stream Control Transmission Protocol”, Proceeding of the Internet and Multimedia Systems and Applications, 2003.” suggest the extension of SCTP for load-sharing, the main idea being to create a per-path data-unit sequence number that transforms the per-association SCTP congestion control to a per-path congestion control. However, this involves changes in the SCTP packet format, and updates at both the sender and the receiver.
Iyenger et al, “Concurrent Multipath Transfer Using SCTP Multi-homing”, Tech Report 2004-02, CISC Dept, Univ of Delaware, 2003 discuss Concurrent Multi-path Transfer (CMT) in SCTP. Researchers on Concurrent Multi-path Transfer agree on the need for structural modifications to congestion control, acknowledgement processing and retransmission mechanisms for independence among the different paths.
Ye et al. in “IPCC-SCTP: an enhancement to the standard SCTP to support multi-homing efficiently”, in: Proceedings of the IEEE International Conference on Performance, Computing, and Communications (ICPCC 2004), Phoenix, Ariz., USA, 2004, pp. 523-530IPCC-SCTP proposed changes to standard SCTP in order to further benefit from multipath features. These changes consist of decoupling the TSN (Transmission Sequence Number) from the congestion control mechanism by introducing a new virtual sequence number called the Path Sequence Number (PSN) for congestion control on each path.
Westwood SCTP with Partial Reliability (W-SCTP-PR) as introduced by Fiore, in “Concurrent multipath communication for real-time traffic”, Computer Communications, v.30 n.17, p. 3307-3320, November, 2007 is based on the SCTP-PR extension. IPCC-SCTP and the congestion control of TCP Westwood and also Mascolo et al in “Performance evaluation of Westwood+TCP congestion control, Performance Evaluation 4” (55) (2004) 93-111.
Based on a per-path congestion control algorithm, W-SCTP-PR introduces a per-path cumulative TSN Ack point and updates it after processing a meaningful SACK. W-SCTP-PR also provides a scheduling algorithm, based on the Westwood bandwidth-estimation technique described by Mascolo et al, to estimate the available bandwidth over each path in the association. Bandwidth estimation is made by considering the time between sending data and receiving the corresponding acknowledgment through the same path over which the data was sent. This modifies standard SCTP behavior which delays SACK and may acknowledge through another path than that over which the data was received.
Previous change made to SCTP to support using several paths to send data focuses on the fact of separating congestion control for each path to control paths independently. This split the multipath association to independent per-path associations. Little attention has been paid to using a global congestion control over the multiple paths.
One wishes to modify SCTP to support the multipath while maintaining only one congestion control window for the whole association that controls multiple paths at the same time. Using one congestion control window would allow better controlling the sending rate over the whole association.
Today, multipath protocols are transport layer protocols as multipath TCP or SCTP (Simple Control Transport Protocol). These protocols have a “per path” TCP like congestion control that has the following drawback: when a path slows down, its congestion window decreases (typically divided by 2) and the path cannot contribute efficiently to the multipath transmission until it recovers its full window. Therefore overall transmission does not fully operate the multipath capability.
Most of the multipath work is based on having one TCP like congestion control mechanism per path. Westwood SCTP_PR algorithm provides a load balancing technique that computes, for each path, the bandwidth estimate (a la Westwood) and an estimated reception time based on the bandwidth estimate and path congestion control related information. The scheduler always gives its preference to the path having the smallest computed reception time.
One of the goals of the present invention is to propose to operate a unique congestion window for all the communication paths involved in the multipath session. In addition, the proposed solution computes, for each path, in function of the measured RTT (Round Trip Time) a ratio of total data to be sent to this path.
As exposed above, until now little attention has been paid to using a global congestion control for all the paths of an association. One of the goals of the present invention is to propose a multipath mechanism which can be concurrent while maintaining a single congestion control window that controls multiple paths for the whole association at the same time.
USPTO Backgrounds
USPTO Backgrounds