and TRUMP/RBCC on a REAL network
scenario which has an obvious congestion `hot spot', as shown in
Figure 2.
TRUMP and RBCC have been implemented as transport and router mechanisms
in the REAL network simulator [Keshav 88][Keshav 91].
This provides an opportunity
to compare TRUMP/RBCC's congestion control with an existing method. This
section describes a comparison of TCP Reno and TRUMP/RBCC on a REAL network
scenario which has an obvious congestion `hot spot', as shown in
Figure 2.
The scenario shows a number of nodes connected by full-duplex links. All links have a data rate of 10Mbps, except for the link between routers 2 and 3, which is a 64kbps link. The 10Mbps links have a latency of 1 sec, and the 64kbps link has a latency of 1 second.
There are four data flows, 5 10, 6 11, 7 12 and 8 9. All cross the 64kbps link, but all start at different times. Thus the link between routers 2 and 3 is the bottleneck in the scenario, and should cause congestion in those routers.
Note that all data flows have corresponding acknowledgment flows in the reverse direction. Note also that the data flow 8 9 is in the reverse direction to the other data flows.
The REAL input file containing Scenario 7 is given in Appendix A.
Given Scenario 7, it is simple to compute the optimum rates for each of the sources; the calculations are given in Appendix B. The following table summarises the rates; the parameter t is the simulation time in seconds.
| Time t (seconds) | Optimum Rate (bps) | |||
| Source 5 | Source 7 | Source 8 | Source 6 | |
| 0<=t<12 | 64,000 | |||
| 12<=t<18 | 32,000 | 32,000 | ||
| 18<=t<=140 | 31,168.8 | 31,168.8 | 62,337.7 | |
| 20,779.2 | 20,779.2 | 62,337.7 | 20,779.2 | |
| 31,168.8 | 31,168.8 | 62,337.7 | ||
| 32,000 | 32,000 | |||
In reality, no rate-based congestion scheme could predict these values perfectly. However, they provide a baseline to compare the rates calculated by the RBCC scheme.
There are several indicators of network congestion:
There are several indicators of network congestion:
The first two indicators cannot be used by themselves as congestion indicators. Packet loss is caused by both network congestion and bit errors. Increasing round-trip time is caused by network congestion and lower available bandwidth to the source (competing sources). Window-based transport protocols such as TCP, however, do used these as congestion indicators. The last three indicators are reliable congestion indicators. We will look at all of these indicators and some other measured factors in the following sections.
Packets are transmitted by a source in monotonically increasing sequence number, barring retransmissions, with the derivative of sequence number versus time giving the effective transmission rate of a source. Figure 3 show the sequence number for each packet transmitted by sources 5 and 6 using TCP and TRUMP.
TRUMP's sequence numbers rise smoothly, controlled by the rate values calculated by RBCC. TCP's rate is much more jagged, caused by its window size changes which reflect packets lost by the destination. Note in particular the early rate fluctuation for TCP source 5.
The plot for sources 7 and 8, Figure 4, shows similar characteristics. TCP transmits packets for source 8 (the reverse data flow) at a much slower rate than TRUMP/RBCC. This is surprising, given the fact that in this scenario TRUMP/RBCC did not lose any packets whatsoever; there must have been adequate bandwidth for source 8 which was not used by TCP. For sources 5, 6 and 7, TCP settles down to a transmission rate which is similar to TRUMP's.
In Scenario 7, TRUMP sources do not lose any packets whatsoever. TCP sources, on the other hand, continually lose packets throughout the life of their transmission. Most packet losses are at the beginning of the data flow (until the optimum window size is reached), and TCP slowly loses packets after that as it tries to open its sliding window to take advantage of any new excess bandwidth. Figure 5 shows the packet losses by TCP.
One of the best indicators of network congestion is a router's average queue lengths for its output interfaces. If a queue has an average length (in packets) less than 1, that interface is underloaded. If a queue has an average length greater than 1, then it is receiving more packets than it can transmit, and is overloaded. A queue length of 1 indicates an optimally loaded interface. As a queue grows in length, packets suffer delays in retransmission at the router, increasing end-to-end delays and round-trip time. All queues are finite in length, and a router must drop packets when there is no space left to queue incoming packets.
In Scenario 7, routers 2 and 3 can only buffer 15,000 bytes (10 data packets). If the router cannot buffer the packet, it is immediately discarded (FCFS queueing and Drop Tail packet dropping). Figure 6 shows the queue lengths (in packets) for router 2.
This plot is cluttered. For router 2, there are several peaks in queue length where TCP's excessive rate has caused lost packets, due to its window resizing mechanism. TRUMP/RBCC nearly always keep the queue length for router 2 between 0 and 2 packets. The only time when the queue length exceeds 2 packets is when source 6 begins transmission at time 140, where the queue length reaches 3 packets.
In Scenario 7, the end-to-end delay for a packet from source 5 must be at least 1.188 seconds, given the link latencies and packet propagation time. Figure 7 shows the measured end-to-end delay of source 5 with both TCP and TRUMP. TRUMP has an end-to-end delay between 1.19 and 1.38 seconds; TCP's value oscillates between 1.19 and 3.06 seconds, due to the oscillation of the queue size in router 2. The end-to-end delays for sources 6 and 7 show the same behaviour. The low end-to-end delay variance exhibited by TRUMP/RBCC is particularly good for time-sensitive data such as real-time voice or video transmission.
Another indication of network congestion, closely tied to average queue lengths, is the utilisation of a link. Together with the queue lengths, the link utilisation shows whether an output link is underloaded or overloaded. Figures 8 and 9 show the utilisation of the link in the direction of router 2 to router 3 for TCP/IP and TRUMP/RBCC, respectively.
Both TRUMP and TCP/IP essentially fully utilise the link. TCP/IP shows occasional dips due to window shutdown, and TRUMP shows dips due to rate recalculations as sources start and stop.
Note that the data obtained by REAL for link utilisation is coarse. REAL periodically calculates the link utilisation by dividing the amount of data transmitted over the link by the time period. If the period is too small, the utilisation information is inaccurate, being sensitive to packet scheduling etc. If the period is too long, the utilisation value is more accurate, but is the average utilisation over a larger time period. I used a time period of 2 seconds for the utilisation measurements.
The utilisation of the link in the direction of router 2 to router 3 shows that TRUMP fully utilises the link while source 8 is transmitting, with only acknowledgment traffic passing over the link when source 8 stops. TCP, on the other hand, never fully utilises the link with traffic from source 8.
The optimum rates for TRUMP sources in Scenario 7 were given in Section 5.1. Figure 11 shows the actual rates returned from RBCC. As can be seen, the rates used by the TRUMP sources match nearly exactly with the optimal rates. There are slight delays due to round-trips which cause the TRUMP sources to adopt new rates after the optimal time. Initial bitrates are correctly found after TRUMP's two-way connection handshake. The close correspondence between the optimum rates and RBCC's calculated rates indicates that RBCC's rate calculation method is successful, and fair to all traffic sources.
