This invention relates to peer-to-peer applications using asymmetric communication networks.
The success of peer-to-peer (P2P) applications hinges on users' willingness to contribute unused storage and network bandwidth to serve other peers. While broadband residential networks have become commonplace in many countries, many of them offer broad bandwidth only in the downlink, i.e., from ISP to user host. By contrast, the uplink bandwidth is typically significantly lower, ranging from tens to hundreds of Kbps as compared to a downlink's multi-Mbps bandwidth. This is particularly common in residential networks built on ADSL and xDSL technologies [1]. (Reference numerals refer to documents listed below.)
While this type of bandwidth-asymmetric network does not preclude the use of P2P applications, it nonetheless creates a new problem for such applications when the data are transported over TCP. Specifically, in P2P applications such as BitTorrent (from BitTorrent, Inc. of San Francisco, Calif.), many users have observed that if the upload data rate is too high, e.g., close to the uplink bandwidth limit, then the achievable download data rate will be severely degraded.
To illustrate this problem an experiment as depicted in FIG. 1 (without the inventive element shown therein) was conducted and the achievable download data rate versus upload data rate for a P2P software called Azureus [2] was plotted. (Azureus is an implementation of BitTorrent.) This software allows the user to configure the maximum upload data rate and through this feature, impact on the download data rate is seen in FIG. 2, where download data rate was drastically reduced from around 900 Kbps to less than 200 Kbps when the upload data rate limit was increased beyond 120 Kbps (close to the 125 Kbps uplink bandwidth limit).
To remedy this problem, many P2P applications (e.g., Azureus, utorrent, BitTorrent, etc.) allow the users to manually configure the upload data rate limit so that a reasonable upload data rate can be used (or else P2P will not work) while keeping the download data rate to fully-utilize the broadband network downlink. Clearly this ad hoc feature is not very user-friendly nor can it adapt to the underlying network properties automatically. A more practical approach is needed.
Literature Review
Bandwidth-asymmetric broadband networks have existed for decades. Therefore numerous researchers had developed solutions to tackle performance problems in such networks. More recent works tackled the problem in the context of having competing traffic in the uplink. Three categories are considered, namely, network layer approaches, transport layer approaches, and application layer approaches.
Network Layer Approaches
An effective network layer approach is to implement priority queuing in the network device connected to the uplink. The principle is to schedule packets from the receiver based on their packet type and gives higher priority to ACK packets [3, 4, 5]. Thus even under heavy uplink data traffic ACK packets will still not be affected.
Transport Layer Approaches
Transport layer approaches rely on modification to the transport protocol of the sender, the receiver, or both. The principle is to enable the sender transport to distinguish downlink congestion from uplink congestion, and only react to the former during congestion control [6, 7, 8]. Specifically, since TCP uses RTT (return trip time) to provide congestion control, both uplink congestion and downlink congestion will affect the sending rate which is undesirable. If the transport can separate RTT into FTT (forward trip time) and BTT (backward trip time), then it will be able to react to downlink congestion only and become immune to uplink congestion. This can be accomplished using the TCP timestamp extension described in RFC1323 [9].
Application Layer Approaches
An application layer approach refers to those solutions which can be implemented entirely within an application without modification to the lower layers such as the transport protocol, the network protocol and network devices. Only one known attempt has been found, namely, in the form of an implementation called Auto-Speed, as in the Azureus [2] P2P client software. The Auto-Speed module in Azureus was not well-documented. However, it is configured so as to control upload data rate limit by monitoring the RTT to a Google host. An adaptive algorithm is then used to increase and decrease the limit based on variations in the continuously measured RTT.
It has been established that TCP throughput performance primarily depends on the path RTT and the packet loss rate [11-12]. Experiments measured the following at the ADSL user: download throughput, upload throughput, RTT, and packet loss. The results are summarized in FIG. 3. The results clearly show that RTT 32 increases consistently with higher upload throughput as congestion built up. By contrast, the packet loss rate 34 remains at a low level even at high upload data rates. Contrasting this with the download throughput in FIG. 2 reveals that the download throughput degradation beginning at the upload data rate of 640 Kbps is in fact primarily due to the increased RTT 32. The implication of this observation is RTT can be used as an indicator of uplink congestion so that the system can react by controlling the upload data rate limit to prevent congestion from occurring.
Further experiments measured the RTT distributions when the uplink data rate limit was set to 400 Kbps and 1000 Kbps, respectively. RTT distribution histograms are shown in FIG. 4. With the low upload data rate limit of 400 Kbps, the RTT distribution 36 has a small mean value of 204 ms and a narrow distribution (STD=13 ms). It is also one-sided as the minimum RTT is bounded from below by the propagation delay.
By contrast, at the high upload data rate limit of 1000 Kbps the RTT distribution 38 has a significantly larger mean value (506 ms), and the standard deviation is far larger as well (65 ms). Comparing the two distributions suggests that it is possible to detect and distinguish them so that the application can automatically adjust the upload data rate limit to prevent congestion in the uplink.