This chapter verifies the effects of the FQRS through simulation by ns-2 [18] in terms of the proportional fairness and sharing, user-perceived latency, the relationship between the access link utilization and value of Wmax, and the choice of F and Umax.
4.1 Topology
The HTTP/Cache class in ns-2 acts as a web proxy cache, and sits between clients and web servers. It intercepts the requests sent from clients and forwards them to the remote servers if the requested data is not cached yet. Therefore, this work disables the cache function in HTTP/Cache and implements FQRS in the class.
Fig. 7 Simulation topology for three classes with service ratio 4:2:1
Figure 7 shows the topology used in the simulation. The FQRS gateway provides three classes, Class1, Class2, and Class3, with the service ratio 4:2:1. Each class involves three clients and all clients connect to remote web servers through the FQRS gateway. The link between the FQRS gateway and every client is 10Mbps with 2 ms propagation delay. The access link connecting the FQRS gateway and the ISP router is configured as 2Mbps capacity with 10ms propagation delay. The ISP router connects
to twelve servers with twelve independent links. These servers are grouped into two server farms, each involving six servers. The two farms represent overseas servers and domestic servers. Links to these servers have a uniform distribution, as shown in Fig.
7. By the statistics from the real Internet [19], the web page size is a lognormal-distributed random variable X with ln(X)=9.357 and σ =1.318. The average response size is 27,656 bytes.
4.2 Weighted Fairness and Sharing
We demonstrate that FQRS provides proportional bandwidth between classes and the idle bandwidth can be shared by active classes. Four phases are included in the simulation and the duration of each phase is 200 seconds. In the first phase, all of the three classes have backlogged requests. In the next two phases, Class1 and Class2 stops requesting separately, and then both of them have backlogged requests again in the last phase.
Fig. 8(a) depicts the throughput of each class in every recomputing interval over the 800 seconds. Fig. 8(b) shows the average throughput in each phase. During the first phase, the three classes get proportional bandwidth in the service ratio 4:2:1. We measure the short-term fairness of service ratio among classes through fairness index [22]. The fairness index, defined as
∑
= the sending rates of competing flows and K is the number of sampling,in this phase is 0.89. In the second phase, the idle bandwidth freed by Class1 is shared by Class2 and Class3 proportionally. Both of the bandwidth obtained by Class2 and Class3 increase in this phase, and the usage ratio between them is still 2:1. After Class2 stopping requesting in the third phase, Class3 occupies all bandwidth until the end of this phase.
During the second and the third phase Class 1 and Class 2 still obtain a bit of bandwidth separately due to their unfinished transactions. Once all idle classes have
requests again in the last phase, the three classes obtain the bandwidth in the expected proportion, 4:2:1, again. Compare the total bandwidth usage in the first phase and the fourth phase, and the one in the first phase is lower because it costs time to raise the bandwidth utilization in the initial state.
Fig. 8 bandwidth usage of three classes with service ratio 4:2:1 in four phases
4.3 Lower Average Latency
When a FQRS gateway is deployed, the user-perceived latency can be (a) Bandwidth usage of three classes depicted every account interval
0
(b) Average bandwidth usage of three classes in four phases
decomposed into transmission time and queuing time. The transmission time is defined as the time spent on transmitting both of requests and responses between the FQRS gateway and remote servers. The queuing time represents the time when the request is queued in the FQRS gateway. The time in transmitting packets between clients and the FQRS gateway is small and can be ignored. Besides, server answering time is always zero in ns-2.
Fig. 9 User-perceived latency comparison by decomposing time factors: queuing time and transmission time
The simulation scenario here is the same as that used in the first phase in section 4.1. Fig. 9 illustrates the decomposition of user-perceived latency for the three classes, the average latency among all classes, and the latency if no FQRS is deployed, denoted as non-FQRS. First, by comparing the left three bars, the different user-perceived latencies are experienced by the three classes. They have different queuing time in FQRS since they have different weights.
Second, by comparing the right two bars, the average latency (6.76 secs) in FQRS is shorter than that in non-FQRS (8.83 secs) by 23.44%. It is because the average transmission time in FQRS (1.5 secs) is far shorter than that in non-FQRS (8.83 secs). The transmission time in FQRS is reduced as a result of reasonable
2.95
Class 1 Class 2 Class 3 Average Non-FQRS
number of concurrent outstanding responses. Section 4.5 with Fig. 11 would further support the hypothesis.
4.4 Adjustment of Window Size
This section observes the relationship between access link utilization and the value of Wmax. Clients in the three classes send requests in the 600-second duration except the middle 200 seconds. During the middle 200 seconds, clients in Class1 and Class2 stop sending requests. That comes out insufficient requests so that the FQRS gateway may have no request to send out.
Fig. 10 reveals the relation between the access link utilization and the value of Wmax. The utilization of access link stays around 0.95 as the expected Umax in the first and last 200-second periods because of sufficient arrival requests.
In the 200th~400th sec, the utilization falls apparently due to the insufficient arrival traffic, and the value of Wmax is constant. It is in vain to raise the value of Wmax
when the incoming requests are too few to occupy all window slots. Therefore the value of Wmax keeps steady as described in equation 4. Because of insufficient arrival requests, there are often some window slots are free. Once the last packet of a response returns, queued requests can be scheduled out as more as possible until no more requests can be sent or no more window slot is available. That is why the value of W in Fig. 10 varies with a wide range during the 200th~400th sec.
0
Fig. 10 The size of Wmax is steady in case of insufficient traffic.
4.5 Choice of F and U
maxThis section examines the choice of F and Umax, two parameters can be configured by administrators. This examination starts with the effect of F, and then on the effect of Umax.
1) Effect of F: According to the examination on the effect of F between 1 and 16 when Umax is assigned to 0.8, 0.9, 0.95, and 0.99, the bandwidth utilization is not susceptible to the value of F. When the value of F is smaller than 16, the degree of bandwidth utilization can reach 95% of expected Umax, even though Umax is high as 99%. From this examination, it is suggested that value of F is set between 4 and 8 because they can come out best bandwidth utilization with respect to the expected Umax.
2) Effect of Umax: Fig. 11 depicts the user-perceived latency, the queuing time spent in FQRS, and the number of queued packet at the ISP-side router when Umax is assigned to 0.65, 0.7, 0.75, 0.8, 0.85, 0.9, 0.95, and 0.99 while F is assigned to 4. As Umax increases, the user-perceived latency and the queuing time reduce meanwhile the number of packets queued in ISP router rises. Raising Umax follows shorter user-perceived latency, because more responses can be transmitted concurrent and the bandwidth can be utilized more. However, the raise also causes packets to be queued in ISP router because of less free bandwidth for eliminating the queued packets as Umax is high. From observation of Fig. 11, the value of Umax is suggested to be set between 90% and 95%.
Fig. 11 Variations of user-perceived latency, queuing time, and the number of packets queued in ISP-side router under various Umax
0 2 4 6 8 10 12
0.65 0.7 0.75 0.8 0.85 0.9 0.95 1
Umax
Time (sec)
0 10 20 30 40 50 60 queue length Latency
Queuing Time
ISP packet queue length