Internet has evolved to provide a multitude of services, more and more enterprises and users use Internet to exchange various kinds of information, causing that the volume of traffic on Internet grows rapidly. Generally speaking, ISPs are willing to invest a lot of money to expand the backbone bandwidth to provide their customers good surfing. However, to minimize costs, their customers often delay upgrading the bandwidth of the access link for as long as possible, and the insufficient bandwidth at the access link results in the serious congestion and long transmission latency. Thus the access link is still the potential bottleneck for enterprises and users who want to access the Internet.
For enterprises, in order to avoid such congestion from degrading the transmission of important connections, some levels of Quality of Service (QoS) must be provided.
Currently the common solution to this requirement is deploying the packet-level bandwidth management [1] at an access gateway. The deployment at the access gateway is undoubted because enterprises do not need to install any software into and modify any configuration on their PCs and servers. However, managing the bandwidth of the access link by a packet-level scheduling mechanism at an access gateway has three problems:
Low scalability: The segment of a file or a web page is usually decomposed to a
great amount of packets. To manage the link bandwidth, the packet scheduling has to decide the releasing order and time of each packet. This per-packet processing costs much CPU resource and increases the complexity on scheduling, causing the scalability problem.
Scheduling behind the downlink bottleneck: In general, without ISP’s support, the
enterprise can only deploy the bandwidth management at the local gateway. Such a management mechanism schedules the downlink packets behind the bottleneck, the access link, which the downlink packets have already passed through. Therefore, the downlink scheduling behind the access link is meaningless. Actually, these packets should be delivered to end hosts immediately without any scheduling because the bandwidth within enterprise’s intranet is far larger than the bandwidth of the access link.
Excessive concurrent transmissions: The packet-level scheduling mainly considers
packet delay differentiation between various classes, but does not care which packets belong to one file within a class. When too many files in one queue are transmitted simultaneously, each file may only grab a little bandwidth, implying that all users in this class have to experience a long transmission time before they get the complete file.
The above three problems reveal the inefficiency and ineffectiveness of packet scheduling. Fortunately, scheduling packets is not the only way for managing bandwidth in the today Internet. Most applications running over the Internet adopt the request-response model; that is, a client sends a request to a server, and then the server returns a response to the client. Request scheduling is used in some recent studies to provide Web QoS [2]. These studies provided QoS services on a single Web server [3-6], caching proxies [7-8] and server farms [9-10]. No studies discussed how to design request scheduling at the access gateway. This work proposes a novel approach, the mechanism at an access gateway, ReQuest Scheduling (RQS) which schedules requests to manage the bandwidth of the access link. The RQS achieves three objectives:
1) High scalability: According to [11], the size of one request is 1/10 long as that of one response averagely. The ratio indicates that scheduling requests is more efficient than scheduling packets of responses.
2) Differentiated and shared bandwidth: By controlling the amount of requests released from various classes, RQS can allocate the bandwidth of the access link to
different classes for transmitting the response packets. Besides, by adopting the Deficit Round-Robin scheduling algorithm [12], free bandwidth can be shared among all active classes.
3) Reducing congestion: By controlling the releasing time of a request RQS can
roughly estimate the return time of its response. Thus RQS can avoid too many responses competing for the access link simultaneously, reducing the congestion occurrence at the access link and then shortening the mean transmission time of a response.
Note RQS not only can schedule outgoing requests to manage the downlink bandwidth, but also can schedule incoming requests to manage the uplink bandwidth. In fact, the complexity and effect of scheduling incoming requests is easier and stabler, respectively, because the servers accessed by the incoming requests are very close to the access gateway. However, for clearer description, this work first emphasizes on scheduling outgoing requests, and then considers handling incoming requests.
The rest of this paper is organized as follows. Chapter 2 presents the operation model and three components of RQS. Chapter 3 describes the algorithms used in each component and proposes a compensation mechanism for the case that the response size cannot be accurately estimated. The simulation results, in Chapter 4, demonstrate that RQS actually achieves the above three objectives and reveal how the dynamic transmission rate and response delay affect RQS on fairness and link utilization.
Chapter 5 discusses the scenario that RQS manages the uplink bandwidth of the access link. Finally, the conclusions and future works are given in Chapter 6.