Aggressiveness and Responsiveness

To demonstrate the fast-convergent behavior in WARC, an on/off CBR traffic with obviously different rates between on and off periods is used, as shown in Fig.

3.16. Such traffic brings dramatic changes on the packet loss condition and thus provides the required transient-state scenarios. In [BBF01], such an oscillating CBR traffic is used to observe whether GAIMD, TFRC, IIAD, and SQRT use the same bandwidth as TCP. The bottleneck in the test is a 16Mbps link managed with Drop-Tail, where the rate of the on/off CBR traffic oscillated between two values, 15Mbps and 10Mbps, to vary the bandwidth available for the TCP-friendly flow to 1Mbps and 6Mbps, respectively. The propagation delay of flows was 30 ms, and the

Fig. 3.15. The smoothness of each scheme over different time scales.

WARC TFRC TEAR

SIMD

queue size was set to 1.5 times the bandwidth-delay product.

Fig. 3.17 first shows that WARC has the fast aggressiveness when additional bandwidth becomes available at the 450^th second. WARC like SIMD converges toward the new rate within about 20 seconds, which is shorter than GAIMD, TFRC and TEAR. The fast aggressiveness results from that WARC forgets the measured packet loss conditions earlier than a fixed number of RTTs, but TEAR and TFRC cannot do it, as mentioned in Chapter 3.2.1.

On the other hand, by using the HR procedure, WARC like TFRC and TEAR has the fast responsiveness at the 600^th second. A fine look at Fig. 3.17 around the 600^th second reveals that the HR procedure in WARC is invoked at 603^th second. Once the HR procedure is invoked, the rate of WARC immediately reduces to the expected TCP rate. Fig. 3.18 shows the number of losses encountered by each schemes between the 600^th and 620^th second, normalized with that by TCP. Obviously, by using HR, WARC encounters fewer losses than GAIMD and SIMD before reducing its rate toward TCP’s.

Fig. 3.17. The comparison between five TCP-friendly schemes on aggressiveness and responsiveness under the on/off CBR background traffic

GAIMD

SIMD TCP

WARC TFRC

TEAR

Fig. 3.16. The topology with oscillating CBR background traffic, used to test TCP-friendly schemes in terms of aggressiveness and responsiveness

S D

R1 R2

100Mbps

2ms 100Mbps

16 Mbps 2ms 26 ms

S’ D’

TCP-friendly sender

on/off CBR sender

TCP-friendly receiver

on/off CBR receiver Drop-Tail

Notably, in Fig. 3.17 the curve WARC’ plots the rate of a flow controlled by WARC without the one-RTT reduction procedure. Obviously, the curve is more oscillatory than that of WARC since the flow encounters more packet losses when the queue of the bottleneck is overflowed. The result confirms that the one-RTT reduction procedure prevents a WARC flow from the sequential losses and the rate oscillation when the flow alone passes through a Drop-Tail link.

Next, we observe whether WARC uses the same bandwidth as TCP under links with various frequencies of oscillating CBR traffic. In this test, the length of the on/off period of the CBR traffic is varied from 2 seconds to 128 seconds. Fig. 3.19 plots the average rates of WARC and other TCP-friendly schemes, normalized with that of TCP for comparison. Obviously, when the oscillating period is smaller than 16, all schemes intends to keep its rate smooth, so they get less bandwidth than TCP.

However, under the link with long oscillating period, since WARC like SIMD has the fast aggressiveness to immediately use the available bandwidth, it can use the similar bandwidth as TCP.

Fig. 3.18. The number of losses encountered by WARC, WARC without HR, and other four schemes between the 600^th~ 620^th second are plotted, which are normalized with that by TCP.

1.0 1.2 1.4 1.6 1.8 2.0 2.2

TFRC TEAR W ARC GAIMD S IMD W ARC w /o HR

norm. # of losses

Fig. 3.19. The normalized throughputs of TCP-friendly schemes under an oscillating CBR traffic

3.6 Related Work

This work focuses on congestion control schemes which use smooth and TCP-equivalent rate to send packets over the Internet. These schemes like TCP NewReno and SACK consider packet loss as congestion signals to adjust their rates.

Actually, besides packet losses, the RTT variation can be used to detect congestions, as in TCP Vegas [BP95] and FAST [JLH07]. Although RTT-based schemes provide a smooth rate too, they may use the network bandwidth unequal to that used by loss-based versions of TCP [TWH05], which still take charge of carrying most traffic over the Internet. C. Zheng and V. Tsaoussidis [ZT06] recently proposed a scheme using both losses and RTTs, which may be a solution to the unfairness problem.

All the schemes mentioned above have a low barrier to deploy into the Internet, because they detect congestion by the packet loss or/and delay and need not any feedback from routers. However, adjusting rate only by loss and delay may not work well in high Bandwidth-Delay Product (BDP) networks [LPW03][KHR02], which a future Internet may belong to. Therefore, researches, e.g. [KHR02] and [XSS05] , consider a tight corporation model between congestion control schemes and routers.

XCP [KHR02] is such a control scheme and requires multiple-bits congestion-related feedback from routers. However, since there is no space in IP header to carry these bits, XCP has a high barrier to be deployed in the Internet. Recently, VCP is proposed in [XSS05] to use two bits to provide the similar effect as XCP. Although VCP overcomes the problem in XCP, it still requires that all routers on the path encode the level of congestion in the IP header. Therefore, the schemes which require feedback from routers, e.g. XCP or VCP, may not be soon applied in the Internet to carry streaming traffic.

Besides the congestion control, other factors must also be considered when designing a protocol for carrying streaming traffic. E. Kohler et al. [KHF06]

discussed these factors in depth, and proposed the Datagram Congestion Control Protocol (DCCP). DCCP allows free selection of a congestion control scheme, and therefore is the most realistic means for practical use of schemes addressed in this study. The protocol currently only includes two schemes, namely TCP-like and TFRC.

We strongly encourage adding other schemes to this protocol.