FQ disciplines approximate the GPS model can schedule packets well. However, as mentioned below, two problems may occur in request scheduling by FQ disciplines.
The user traffic handled in a request scheduling includes the uplink requests and downlink responses, not just the downlink packets.
2.1 The Timing of Releasing Requests
2.1.1 Problem Statement
The FQ disciplines send the next packet when the last packet has been transmitted. The bandwidth of a bottlenecked link is totally consumed by the scheduled packets themselves. That is, the packet transmission monopolizes the link bandwidth. Therefore, once a packet is selected from a queue by a scheduling discipline, it is transmitted in the rate equal to the capacity of this link.
However, the request scheduling cannot send the next request following the last request right away. The bandwidth of bottlenecked downlink is consumed by the responses, rather than scheduled requests. Sending requests one-by-one results in too heavy concurrent outstanding responses because the response is usually much larger than the request and a response transmission does not monopolize the downlink bandwidth. Too many concurrent outstanding responses cause the downlink in a serious congested condition.
On the other hand, it is not appropriate in request scheduling that no request is allowed to be sent until the preceding request gets its response completely. When a request is scheduled, the bandwidth of the bottlenecked downlink is not consumed
immediately until the corresponding response returns. Obviously, sending the next request until receiving the whole preceding response would waste the bandwidth of downlink, causing low bandwidth utilization.
2.1.2 Potential Solution
Obviously, appropriate outstanding responses are necessary in scheduling request with FQ disciplines. The request scheduler WebBM, our previous work, allocates the bandwidth among responses precisely to avoid the link from waste and congestion.
For not wasting, WebBM releases next request in advance so that its response can exploit the idle bandwidth as soon as the preceding response finishes. For not congestion, WebBM only releases the request whose bandwidth requirement of response fits the coming idle bandwidth.
To forecast when and how many idle bandwidth there is, WebBM needs the information about the rate and the finish time of each response transmission. To decide which request is the next and its advanced releasing time, WebBM needs the potential bandwidth requirement, and the time between releasing a request and receiving the first packet of its corresponding response. Although the required information can be abtained from historical statistics, inaccurate information may affect the access link utilization. Besides, no historical data exists in the initial state, and thus WebBM may encounter great difficulties in an open environment.
2.2 The Determination of the Next Request
2.2.1 Problem Statement
Due to the rule of approximating GPS, the FQ disciplines tend to select the packet that would complete service first in the fluid GPS model as the next packet.
Since packets are transmitted in a full capacity of link, the calculation of the potential service completion time only involves two known parameters, packet arrival time and
packet size. Thus, the potential service completion time can be easily calculated when a packet arrives. For two packets arriving at the same time, the packet size decides the order of service completion time. A smaller packet finishes service earlier.
However, for request scheduling, the service completion time of a transaction is unknown. The response size of a transaction is unknown until the first packet of the returning response is got. At that time, the size of a response can be extracted from the application header of this packet. Moreover, a response may not be transmitted in a constant rate. For this reason, request scheduling cannot serve requests simply by the order of service completion time to provide fairness. Hence, the determination of which request will be scheduled as the next is the second problem.
2.2.2 Potential Solution
The RQS [15], another our previous work, had the same four goals as this work:
proportional fairness, bandwidth sharing, congestion reduction, and fully link utilization. It merged the algorithm from WebBM to estimate the timing of releasing next request and a selection discipline derived from the Deficit Round Robin (DRR) [17], which is one of packet-based fair queuing algorithms. DRR provides fairness by proportional quantum in bytes among classes. Class queues are served in a round-robin manner. The quantum of each class’s deficit counter stands for the allowed service amount, i.e. the total length of packets can be transmitted in each round.
RQS measures fairness by counting the size of received responses size. Thus, the quantum of one class stands for the size of responses allowed to be received in one round. When planning to send a request, RQS selects the first request from a queue which is in turn meanwhile owns sufficient quantum for the given corresponding response size. If the quantum is insufficient, the deficit counter of this queue saves the remaining quantum for use in the next round. The scheduler then serves the next class
queue.
The selection discipline used in RQS is designed under the assumption that the size of a response is always given as the request arrives. Inaccurate response size may degrade the fairness between classes. Actually, the response size is unknown when the request arrives, and it is extracted until the first response packet is received in most case. For this problem, RQS has a compensation mechanism to prevent the unfairness resulted from inaccurate estimation of response size at scheduling. Once the obtained real size is different from the estimated one, the corresponding deficit counter is compensated with the difference in size in that round.