4.1 Simulation Environment
The network simulation tool, ns-2 [14], is used to simulate the operation of RQS.
The class Http/Cache in ns-2 models behaves as a simple HTTP cache with infinite size, so it will intercept the requests sent from clients and then will forward them to the web server. Thus, we implement the RQS algorithm on the class Http/Cache.
RQS
Fig. 9: Simulation topology used in this work
Fig. 9 shows the simulation topology used in this work. The RQS gateway provides three classes. Twelve clients connecting to the RQS gateway are equally divided into the three classes. The link between the RQS gateway and a client is 10Mb/s with 2 ms propagation delay. Besides, a 128Kb link with 50 ms propagation delay connects the RQS gateway with an ISP's edge route R to simulate the access link. Next, the route R connects to four servers with four independent links, whose configurations are presented in Fig. 9. The fixed response sizes in the four servers are 40KB, 20KB, 10KB, and 5KB, respectively. The client named as Cx-y represents that it only send requests to server x and their responses belong to class y. In other words, each server has to serve three clients belonging to three different classes. Note that the client can only send the next request until the whole response packets requested by the last request
return.
4.2 Throughput Differentiation
First, we demonstrate that RQS can actually allocate the proportional bandwidth to different classes and let active classes share the free bandwidth. The proportion of the bandwidth allocated for three classes is given as 4:2:1. At the beginning, clients in Class1 and Class2 send requests and after four minutes, clients in Class3 join. Fig. 10 shows the bandwidth usage of three classes during 8 minutes. At 0~4 minutes, Class1 and Class2 occupy the downlink bandwidth and their average bandwidth usages are equal. The reason that the ratio is not 4:2 is that the mean transmission rate of the response traffic in Class1 (55 Kbps) is not high enough to occupy 2/3 bandwidth of the access link (256/3, or 85.33 Kbps). Thus, the Class2 fairly shares the bandwidth with Class1. However, at the 4th min, Class3 starts to occupy the downlink bandwidth. The proportion of the bandwidth usage occupied by three classes is 57:37:18. Compared to the average target ratio between various classes, ( 4/2 + 2/1 )/2, or 2, that under RQS is ((57/37+37/18)/2), i.e., 1.798. The accuracy is 1.798/2=89.9%
0 20 40 60 80 100 120 140
0 1 2 3 4 5 6 7 8
Time (min)
Throughput (Kb/sec)
Total Class1 Class2 Class3
Fig. 10: Downlink bandwidth usage of each class during 8 minutes
4.3 User-perceived Latency
Next, we observe the user-perceived latency experienced by the clients in three classes during 8 minutes. The simulation scenario here is the same as that in Chapter 4.2, except that all clients send requests from the beginning. For the clients accessing the same server, as shown in Fig. 11, the higher class the client belongs to, the shorter user-perceived latency the client experiences. Besides, the differences of latency between various classes decrease with the increase of server’s number, and this phenomenon can be further observed from Fig. 12 and 13. Fig. 12 shows the time queued in RQS and Fig. 13 shows the sum of Delayresp and response transmission time.
Obviously, as shown in Fig. 12, the queuing delay in RQS for different classes determines the differences of latency between classes. That is because RQS delays the release of a request according to its response size, and the response size in Server1 is the larger than other servers. In other words, all clients connecting to Server1 get larger response sizes, i.e. longer transmission times, and therefore have longer waiting times for the next service than the waiting times experienced by clients of Server4.
0 5 10 15 20 25 30 35 40 45 50
Server1 Server2 Server3 Server4
Time (sec)
Class1 Class2 Class3
Fig. 11: Average user-perceived latency
0
Fig. 12: Average queuing time in RQS gateway
0
NoRQS RQS Server1 C1-1 C1-2 C1-3 Server2 C2-1 C2-2 C2-3 Server3 C3-1 C3-2 C3-3 Server4 C4-1 C4-2 C4-3
Time (sec)
Transmission Time Response Delay
Fig. 13: The sum of average Delayresp and response transmission time
4.4 Response Transmission Time
Finally, as shown in the most left group of Fig. 13, the average transmission time of user-perceived latency for all classes under RQS is 68.75% shorter than that under no RQS. Thus RQS can decrease the transmission time, that is, it actually avoids too many connections competing for the access link simultaneously.
4.5 Fairness Improved by the Compensation Mechanism
0
Bias ratio of response size in Class1
Bandwidth (Kb/sec)
Class1 Class2 Class3
Fig. 14: Average bandwidth usage without compensation
0
Bias ratio of response size in Class1
Bandwidth (Kb/sec)
Class1 Class2 Class3
Fig. 15: Average bandwidth usage with compensation
In this evaluation, all clients of three classes send requests from the beginning and the bandwidth allocated for three classes are equal, i.e. the quantum ratio is 1:1:1. Next, assume that RQS can accurately estimate the size of the response, except the response belonging to Class1. The biasing ratio (size used in RQS/ real size) for the clients in the Class1 ranges from 1/10 to 10. For example, the biasing ratio being equal to 10 presents that RQS thinks the size of a response is 100KB although its real size is only 10KB.
This simulation runs in 8 minutes, and the average bandwidth usage is measured from the second minute for stability.
Fig. 14 shows the effect of inaccurate estimation of response size on the fairness between classes, and Fig. 15 demonstrates the improvement of using a compensation mechanism in RR. It is clear in Fig. 14 that wrong response size used in RPC seriously degrades the fairness on bandwidth usage between various classes. In the cases that the biasing ratio is larger than one, the bandwidth usage of Class1 is lower than the expected because its deficit counter in RPC is over-decreased. In the cases that the biasing ratio is smaller than one, the situation is reversed. When RR applies the compensation mechanism, as shown in Fig. 15, the bandwidth usage between three classes is quite close to the targeted ratio, 1:1:1, in all cases.
4.6 The Impact of Inaccurate Delay
respand Transmission Rate
0 20 40 60 80 100 120
1/5 1/4 1/3 1/2 1 2 3 4 5
Bias ratio of transmission rate in Class1
Bandwidth (Kb/sec)
Total Class1 Class2 Class3
Fig. 16: The impact on link utilization resulted from inaccurate transmission rate Fig. 16 shows the impact of inaccurate estimation of the mean transmission rate on link utilization. All clients of three classes send requests from the beginning. The quantum ratio between three classes is 1:1:1. The first observation is the total link utilization is decreased with the increase of the biasing ratio of transmission rate, i.e. the
actual sending rate of the response traffic is smaller than the estimation used in RQS. In addition, although the utilization is higher when the ratio is smaller than 1, serious congestion will occur at the access link, and it is not preferred.
0 20 40 60 80 100 120
1/5 1/4 1/3 1/2 1 2 3 4 5
Bias ratio of delay_resp in Class1
Bandwidth (Kb/sec)
Total Class1 Class2 Class3
Fig. 17: The impact on link utilization resulted from inaccurate Delayresp
Fig. 17 shows the results as Delayresp cannot be estimated accurately. The biasing ratio larger than one means the value estimated in RQS is larger than the actual Delayresp, leading to unexpected response traffic competing for the access link. Contrarily, when the ratio is smaller than one means the actual Delayresp is smaller than the value used in RQS, causing one response cannot follow another finished response well. Therefore, available bandwidth is wasted and the link utilization is going down.
Although inaccurate Delayresp and transmission rate affect the link utilization, but the bandwidth usage ratio of three classes still close to the targeted ratio of three classes, i.e., 1:1:1.