Traffic on Reverse Link

This section looks at performance when there is traffic and congestion on the reverse link. Figure 11 shows we have the same TCP source as in the previous example from A to the Receiver; however, there is also a TCP session running from Source B to Router 1. This example demonstrates TCP-Santa Cruz's ability to maintain a full data pipe along the forward path in the presence of congestion in the reverse path.

  

Figure 11: Traffic on the reverse link

Figures 12 (a) shows the window growth for Reno source A. The growth of Reno's congestion window is considerably slowed as compared to Figure 9(a) when no reverse traffic is present. The periods of linear increase during congestion avoidance until a packet loss have a much longer duration because ACKs are both delayed and lost. Since Reno grows its window based on ACK counting, the slowed reverse path traffic for Source A (because of the data traffic from Source B) prevents Source A from filling the bit pipe as fast as normal, resulting in low link utilization on the forward path. In contrast, Figure 12 (b) shows that the congestion window for TCP-Santa Cruz (n = 5) is relatively unaffected by the reverse traffic on the reverse path and reaches the optimal window size of around 22 packets.

  

Figure 12: Comparison of congestion window growth when TCP-Reno traffic is present on the reverse path: (a) Reno (b) TCP-SC n=5

Table 3 shows the throughput and delay obtained for Reno, Santa Cruz and Vegas. Santa Cruz achieves up to a 68% improvement in throughput compared to Reno and a 78% improvement over Vegas. Because of the nearly constant window size, the variation delay with our algorithm is considerably lower than Reno. Vegas suffers from low throughput in this case because its algorithm is unable to maintain a good estimate for throughput because of the highly varying RTT measurements. Vegas exhibits low delay primarily due to its low utilization of the bottleneck link; this insures that packets are never queued at the bottleneck and therefore do not incur any additional queueing delay from source to destination.

 

Table 3: Throughput, delay and delay variance comparisons for Reno, Santa Cruz and Vegas in the presence of traffic on the reverse link.

Comparison of Throughput and Average Delay
Protocol	Throughput	Utilization	Average delay	Delay variance
	(Mbps)		(msec)	(msec)
Reno	0.823	0.55	134.3	56.2
Santa Cruz n=1.5	1.213	0.81	54.8	0.0034
Santa Cruz n=3	1.312	0.87	60.6	0.0057
Santa Cruz n=5	1.390	0.92	73.4	0.0080
Vegas (1,3)	0.778	0.52	49.5	0.0016