The design and implementation of a real-time data dispatching system

(1)

The Design and Implementation of A Real-Time Data Dispatching System

Nei-Chiung Perng, Neung-Tsung Tsai, Jen-Wei Hsieh, and Tei-Wei Kuo

f

d90011,r89074,d90002,ktw

g

@csie.ntu.edu.tw

Department of Computer Science and Information Engineering

National Taiwan University Taipei, Taiwan, ROC 106

Abstract

This paper describes the design of a real-time data dis-patching system (RTDDS), which is motivated by the needs of a performance guarantee on real-time data services by front-end clients. RTDDS consists of homogeneous ma-chines with a quality of service performance guarantee. We address the resource allocation problems and consider Bin-Packing algorithms to assign requests to machines of RT-DDS. Processes scheduling over each machine is done au-tonomously by SRP-based algorithms. The goal is to maxi-mize the number of concurrent clients and to meet the indi-vidual quality of service requirements of clients at the same time.

1. Introduction

The popularity of Internet has triggered the great de-mand of information technology in recent years. Various vendors now provide services in different styles over the Internet, free or charged, to customers. Issues in how to improve system performance in many ways, such as scala-bility, availascala-bility, reliascala-bility, etc., are under serious inves-tigation. Most work focuses on how to increase the capa-bility of servers, clustered or not, to serve more clients, in-stead of multicasting data to clients based on their individ-ual qindivid-uality-of-service requirements. Such an observation underlies the goal of this research.

Clients over the Internet usually face different statuses of networks and different qualities of services from providers. They often need to deal with different speciﬁcations of services, even under the same service type, such as mu-sic, and have to search for service providers which provide their needed services. Nodes with directory services and quality control are needed in the entire infrastructure for information-services over the Internet. The design and im-plementation of the relaying-service system investigated in

this paper aims at meeting the quality of service (QoS) re-quirements of selected clients with a scalable architecture. We assume that the relaying-service nodes, at one end, are attached to networks with a sufficient network bandwidth to acquire services from service providers. At the other end, the relaying-service nodes cache data from the service providers and relay the data to clients according to the QoS requirements of clients. The relaying-service nodes regulate network traffic from the nodes to clients according to the re-quirements of each client, e.g., a specified number of bytes per specified time units (so that clients are not overflowed with data). A naming service should be provided as well, and multicasting services must also be supported to reduce the workload of the relaying-service nodes. Different from the research work in proxy servers, streaming services, or network bandwidth management, this work is mainly on the design and implementation of relaying services from ser-vice providers to front-end clients, and it could be consid-ered as an extension of ordinary proxy servers.

This paper aims at the design and implementation of a relaying-service system from service providers to front-end clients with QoS guarantees. A real-time data dispatching system (RTDDS) is implemented to demonstrate the feasi-bility of this work. RTDDS consists of a collection of ma-chines, which collectively serve as relaying-service nodes to regulate network traffic from the nodes to clients according to the requirements of each client. RTDDS could be con-sidered as a variation or an extension of proxies; the main goal of RTDDS is to subscribe services on behalf of clients and pass (or multicast) data to clients based on their indi-vidual QoS requirements. The basic assumption is to have sufficient network bandwidth for service delivery from ser-vice providers, similar to that for powerful caching servers for communities. We consider Bin-Packing approximation algorithms to partition workload among machines of RT-DDS. We adopt the stack-based resource protocol (SRP) [2] for autonomous workload scheduling on each machine, where SRP provides a uniform treatment of various multi-unit resources and could be associated with dynamic and fixed priority assignment schemes. RTDDS is designed

(2)

as a message-oriented distributed system which provides load balancing with a broker-based mechanism. We adopt a pure-Java solution which delivers the promise of ”Write Once, Run Anywhere” through the Java Virtual Machine (JVM).

The rest of the paper is organized as follows. Section 2 describes the detailed system design of RTDDS. The system implementation issues are discussed in Section 3. Section 4 provides the experimental results of the system to demon-strate the capability of RTDDS on quality-of-service guar-antee and graceful degradation. Section 5 is the conclusion.

2. Real-Time Data Dispatching System

2.1 System Architecture

Figure 1. System Architecture

Figure 1 shows the system architecture of RTDDS. The objective is to provide ﬁxed-rate relaying-services for clients over different platforms with different QoS require-ments, independent of the data-transmission rates and vari-ations of service providers. RTDDS consists of a collection of homogeneous or heterogeneous machines over a local area network to provide a scalable solution for on-time data delivery. Note that these machines could be heterogeneous in our design At this time we implement the system with ho-mogeneous machines. A combination of master-slave and broker-based architectures is adopted, where a master

bro-ker (MBrobro-ker) runs on one machine of RTDDS to assign

workloads to slave machines so that each slave machine will

then acquire data from service providers by itself and multi-cast the acquired data to clients according to their individual QoS requirements.

Two kinds of brokers for data acquisition and deliv-ery called home broker (HBroker) and destination broker (DBroker) are introduced. When a request comes from a client, it ﬁrst goes to MBroker. The MBroker will assign a HBroker to acquire data from the corresponding service provider and assign a DBroker to send data to the client ac-cording the QoS requirements of the client. The HBroker may cache data from the service provider at its residing ma-chine, depending on the services (which will be discussed in Section 2.2). The responsibility of a DBroker are to ac-quire data from a proper HBroker and to send/multicast the data to clients according to the QoS requirements of clients. The criteria in the assignments of HBrokers and DBrokers are not to overload each slave machine and to maximize the number of serviced clients based on the capability of machines and the QoS requirements of clients. The assign-ment of HBrokers and DBrokers to slave machines will be discussed in Section 2.3.

The naming service of RTDDS is provided by the MBro-ker. It is the responsibility of the MBroker to keep a direc-tory of services. When a client request does not come with a speciﬁc host address, and the directory of the MBroker does not contain service providers for the request, the cur-rent design of the MBroker will simply reject the request.

2.2 Handling of Streams

Services in RTDDS can be roughly categorized into two types: regular and timely services. Timely services are as-sociated with services of data with aging problems so that every piece of (continuous or discontinuous) data of the ser-vices must be delivered to a selected front-end in an on-time fashion. Note that data with aging considerations will have their validity passing with time. For example, the delivery of stock quotes is an timely service because no one wants to complete a transaction with out-of-date data. Regular

ser-vices are serser-vices for data without aging problems, e.g.,

im-pressive scenes of classic movies. However, we must point out that there could be timing constraints in the delivery of data under timely or regular services. For example, the de-livery of a video stream is associated with timing constraints for each frame or each group of frames although the deliv-ery could be classiﬁed as a regular service.

Two kinds of delivery schemes are deﬁned for timely and regular services: non-cached-stream and cached-stream de-liveries. Cached-stream delivery requires RTDDS to cache data from the service providers during the services to the clients. The HBroker who is responsible for acquiring a

(3)

ser-Figure 2. Data Dispatching over RTDDS

vice (from a service provider) during a cached-stream deliv-ery should do the caching, and the caching process should include the notiﬁcation to and a yes-or-no decision from the MBroker. The cached data could be saved for later re-quests from clients. When later on a new request on the cached data comes in, MBroker would assign the HBro-ker to handle the request. As astute readers may notice, cached-stream delivery should only serve for regular ser-vices because the reusing of cached data, e.g., video streams or a popular song, implies that data have no aging prob-lems. Obviously, each machine has a limited capacity in the storage of cached data and the handling of cached data, i.e., I/O operations on retrievals and saving of cached data. The decision of caching should be done by the MBroker be-cause it manages the entire workload of the system. When the capacity of a machine is full, the corresponding HBro-ker should notify the MBroHBro-ker. The MBroHBro-ker would deter-mine the removing of the selected cached data and notify the HBroker.

Non-cached-stream delivery could be associated with ei-ther timely or regular services. No data are cached at any machine. As a result, any such delivery only consumes CPU time, memory space, and network bandwidth. Note that DBrokers are not involved in the decision of caching of data. The main responsibility of DBrokers is on the regulat-ing of trafﬁc to clients. All data are directly from HBrokers, regarding of whether HBrokers supply DBrokers data di-rectly from their caching storage or from the corresponding service providers.

2.3 Resource Allocation

2.3.1 Workloads and Resource Requirements

HBorkers (and their corresponding machines) are units in workload assignments. The workload of each client request

i can be deﬁned by two parameters N i and P i, where i requests RTDDS to provide the clientN

ibytes per P

iunits of time. Several requests of the same data would be from

the same service provider (the same HBroker) but have dif-ferent parametersN

iand P

i. When one or multiple clients request a data, the corresponding HBroker must acquire a service from a proper service provider. The service provider could have ﬁxed or variable rates in passing data to the HBroker.

Let us use three parameters to model the workload from a service provider: N max , N min and P. N max and N min

denote the maximum and minimum numbers of bytes transferred from the service provider within eachP units of time. Given a collection of n client requests T

i = f(N i;1 ;P i;1 );;(N i;n i ;P i;n i )g, letN max i , N min i and P i be the parameters modelling the workload of the HBroker (whereN

max

i and

N min

i denote the maximum and mini-mum numbers of bytes transferred from the service provider within each P

i units of time). Suppose that a well-known dual buffer scheme, which uses one buffer to receive data and another to send data, is adopted1_{. The following} for-mula must be satisﬁed for the minimum size of the buffer:

N min i n max j=1 d P i P 1;j eN i;j whereP i P

i;j for all

1 j n. For the simplicity of implementation, let P

j jP

i;j for all

1 j n. The buffer requirement of the HBroker on the above service is 2N

max

i . Let the workloads of the client requests T i = f(N i;1 ;P i;1 );;(N i;ni ;P i;ni

)g and their corresponding HBroker workload (N max i ;N min i ;P i ) be denoted collec-tively asDW i = ((N max i ;N min i ;P i );T i ). EachDW i is called a HBroker delivery workload in the system.

Suppose that the i

th HBroker is as-signed a collection of m i services H i = f(N max i;1 ;N min i;1 ;P i;1 );;(N max i;mi ;N min i;mi ;P i;mi )g for

clients. The minimum memory space (for the dual buffer scheme) for the HBroker is 2

P m i j=1 N max i;j . Let T i;j = f(N i;j;1 ;P i;j;1 );;(N i;j;ni;j ;P i;j;ni;j )g be the collection of client requests which cor-responds to a workload from a service provider S i;j = (N max i;j ;N min i;j ;P i;j ) 2 H i. Let CH i be the maximum subset of H

i for cached-stream service. When the Stack-Based Resource Policy (SRP) is used for schedul-ing of all resources on one machine, where SRP could use either a dynamic priority assignment scheme (such as the earliest deadline ﬁrst algorithm) or a ﬁxed priority scheduling scheme (such as the rate monotonic algorithm) [7]. The minimum I/O bandwidth requirement is

1_{The implementation of the dual buffer scheme could be done by a}

well-known circular buffering approach where a less amount of memory space is needed. However, when the variation of data transmission from the service provider is large, then the buffer size must be increased to prevent the overﬂowing of the buffer.

(4)

X (N max i;j ;N min i;j ;Pi;j)2CHi N max i;j Disk AccessRate P i;j + X (N i;j;k ;P i;j;k )2T i;j N i;j;k Disk AccessRate P i;j;k 1 A +B i

whereDiskAccessR ateis the worst-case disk access rate (i.e., that including the worst-case seek time and latency delay, unless a good placement scheme is adopted).

Note that B i

=

OneBlock AccessTime MinPeriod

, where OneBlockAccessTime is the worst-case access time for one block access, and MinPeriod is the minimum periods of all client and service workloads. The correctness of the above formula follows from the schedulability analysis results in the research results of the stack-based resource policy and the constant utilization servers [4] and when the earliest-deadline-ﬁrst algorithm (EDF) is used in scheduling disk I/O operations. Note that EDF assigns the request (or process) with the closest deadline the highest priority. We assume that CPU time is always sufﬁcient for each HBroker under the assumption that disk I/O could be handled for the HBroker because I/O is much slower (However, when the assumption is improper, the formula for the CPU bandwidth requirement could be derived in a similar way as that for I/O bandwidth requirement).

2.3.2 Assignments of HBrokers and DBrokers

For the simplicity of implementation, we assume that each machine is assigned a HBroker in this paper. The technical

question here is how to assign service workloads to HBro-kers without overloading any HBroker. Given a ﬁxed set of

service workloads, the HBroker assignment problem could be shown as a NP-Complete problem.

Theorem 1 The HBroker assignment problem is

NP-Complete.

Proof. An instance of the HBroker assignment

prob-lem has a collection of workloadsf(N max 1 ;N min 1 ;P 1 ), ..., (N max n ;N min n ;P n

)g. It is to partition thenservice notices over a given number of HBrokers, under the constraint that the total utilization of each HBroker does not exceed its ca-pacity of corresponding HBroker. This problem is a NP problem since we could guess a partition and verify it in a polynomial time.

We could show that the HBroker assignment problem is NP-Complete by reducing it from the Bin-Packing problem.

An instance of the Bin-Packing problem has a ﬁnite setUof items, a sizes(u)2Z

+

for eachu2U, a positive integer bin capacityB, and a positive integerK[3, 6]. The Bin-Packing problem asks to have a partition ofU into disjoint setsU

1 ;U

2 ;:::;U

ksuch that the sum of the sizes of the items in eachU

iis no more than B?

The reduction is straight forward because the HBroker assignment problem is exactly the same as the Bin-Packing problem withDiskAccessR atebeing a very large number such that the I/O bandwidth requirement could be virtually removed.2

Since the HBroker assignment problem is NP-Complete, approximation algorithms are needed for the assignments. There are excellent approximation algorithms already exist for the Bin-Packing problem, such as Next-Fit and First-Fit [9]. Because the advance of hardware technology already makes memory space a minor issue, compared to the perfor-mance of disks, we propose to apply Bin-Packing approx-imation algorithms to assign workloads to HBrokers with only the considerations of I/O bandwidth requirements. We assume that the memory space is sufﬁcient in the implemen-tation.

The assignment of DBrokers to machines in RTDDS is independent of the assignment of HBrokers in the consid-erations of the architecture design. However, when imple-mentations are considered, each DBroker should be resi-dent on the same machine as the HBroker which is assigned client requests corresponding to the workloads of the HBro-ker. When several requests of the same data come from clients with a distance such that they had better to receiv-ing data from different machines in RTDDS, the assignment of DBrokers, once again, becomes a very difﬁcult problem (which can be, in fact, reduced from a weighted set cover-ing problem given the followcover-ing informal deﬁnition for the DBroker assignment problem):

Let each DBroker have a set of client requests, and each HBroker have a set of workloads for the client requests, where the sets of some DBrokers could have non-empty overlapped subsets. Assume that the underlying network is a broadcast network such that the considerations of net-work overheads could be ignored. When a DBroker and a HBroker are assigned on the same machine, the number of overlapped client requests (for the DBroker) and workloads (for the HBroker) is called the matched number. The

prob-lem is how to assign DBrokers to machines, where the as-signment of HBrokers on machines given, such that the sum of matched numbers of all machines is maximized. Note that

each machine will be assigned exactly one HBroker and one DBroker.

For the purpose of the design goals of RTDDS, we as-sume that each machine is equally good in servicing any

(5)

client request, where RTDDS is mainly designed to reg-ulate network trafﬁc according the QoS requirements of clients. Machines of RTDDS work as an integrated clus-tered ”virtual” machine in processing client requests. We do not allow client requests of the same data being as-signed to more than one DBroker. Furthermore, let a DBro-ker reside at the same machine as the HBroDBro-ker which ser-vices its client requests. The HBroker assignment problem deﬁned above could be extended as the HBroker/DBroker assignment problem, except that the minimum memory space (for the dual buffer scheme) for the HBroker becomes 2 P j=1;mi N max i;j +2 P (Ni;j;k;Pi;j;k)2Ti;j N

i;j;k. The ap-proximation algorithms discussed in the previous para-graphs could be used similarly.

3. System Implementation

3.1 A Master-Slave Architecture

An asymmetric master-slave architecture is adopted in the design and implementation of RTDDS. One master ma-chine is assigned to run MBroker. MBroker must assign workloads to HBroker and DBrokers. The system archi-tecture of RTDDS could be supported by two well-known distributed system architectures: OMG’s Common Object Request Broker Architecture (CORBA) [8] and Sun Mi-crosystem’s Java Message Service (JMS) [5]. CORBA is an open, vendor-independent specification for an architec-ture and infrastrucarchitec-ture which applications can adopt to work together over networks. With the OMG Interface Defini-tion Language and standardized protocols GIOP and IIOP, CORBA allow any CORBA-based program from any ven-dor, operating system, and programming language to co-operate with other CORBA-based programs. JMS, which consists of a set of APIs, provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise. JMS also provides a com-mon API and provider framework that enables the devel-opment of portable, message based applications in the Java programming language.

CORBA and JMS are products designed for different purposes. We choose JMS for the implementation of RT-DDS for two reasons: (1) JMS, which is mainly based on asynchronous communication, provides a connectionless communication approach, where most CORBA implemen-tations depend on TCP-based communications. Note that TCP-based communication is better for reliable communi-cation, but connectionless communicommuni-cation, such as UDP, in general provide better performance over reliable network-ing environments. Since the implementation of RTDDS is over reliable intranet, JMS is chosen as the implementa-tion framework and platform. (2) Java and JMS together

provide a better cross-platform development environment. They provide better portability for the implementations of RTDDS.

Figure 3. Control Flow of RTDDS

Numerous vendors provide JMS products which follows the JMS standard. OpenJMS [1] version 0.7.2 build 14 was used to implement RTDDS, where OpenJMS is an open source implementation of JMS API 1.0.2 specification de-veloped by ExoLab Group. Over the bottom structures pro-vided by OpenJMS, brokers negotiate with each another by instant message exchanging. Figure 3 is the flow of con-trol information when a service provider publishes data to RTDDS: The first step is a registration to the MBroker, in which a service provider sends a service notice to MBro-ker. A service notice consists of the host address, binding port number, and service name of the provider. After receiv-ing a request from a client for a published service (Step 2), MBroker chooses a suitable HBroker and a suitable DBro-ker for service, with the methodology described in the pre-vious section (Step 3). The assignment of a HBroker and the DBroker is done by an invoke message to the HBroker and the DBroker (Step 4). The HBroker and the DBroker both need to send back an acknowledgement back to the MBroker (Step 5). The HBroker then acquires data from the service provider (Steps 6 and 7) and sends the data to the DBroker (Step 8). The DBroker then sends the data to the client based on its QoS requirements (Step 9).

3.2 Implementations of Brokers

To regulate the trafﬁcs of real-time data dispatching to clients, each broker is designed as a multithreaded server to handle concurrent client requests to increase responsiveness and to reduce blocking, as shown in Figure 4. Whenever a new client request comes in for a HBroker or DBroker, a thread is assigned to handle the request. A thread pool is maintained.

The communication between a service provider and a HBroker is done by a TCP-based connection to provide

(6)

Figure 4. Broker Design Diagram

a reliable communication. The communication between a DBroker and its client is also done by a TCP-based con-nection because of the same reason. The communication between a HBroker and its corresponding DBroker is done by JMS-based asynchronous communication to maximize the performance, where we assume the existence of reliable intranet for HBrokers and DBrokers. Note that when clients and servers adopt the Real-Time Transport Protocol (RTP) (which is over TCP and UDP), the implementation of RT-DDS could utilize the ﬂow control of RTP for multimedia data transmissions.

MBroker, HBrokers and DBrokers adopt the following JMS framework for the exchanging of asynchronous mes-sages. MBroker, HBrokers, and DBrokers which send and receive asynchronous messages inherit the interface

javax.jms.MessageListener. Users should implement the onMessage method. While a message delivered to brokers,

onMessage method will be called. import javax.jms.*;

public class RtddsBroker implements MessageListenerf ...

public void onMessage(Message message)f / * write todo jobs here */

g ... g

4. Performance Evaluation

4.1 Experimental

Environments

and

Perfor-mance Metrics

The purpose of the experiments was to evaluate the per-formance (or QoS guarantee) of RTDDS and its overheads.

The RTDDS was implemented in pure-Java over ExoLab OpenJMS version 0.7.2 build 14. The evaluation platform was over several Pentium-III 600MHZ personal comput-ers. In the current version, we generated dedicated Service providers to provide data periodically. They were deployed over a remote network. One of them was connected directly to Hinet (which is provided by Chung-Hwa Telecom ISP) with ADSL (64kbps uplink and 512kbps downlink). Our RTDDS was set up at the Real-Time and Embedded Sys-tems Laboratory at the National Taiwan University. RTDDS was connected to a LAN in the laboratory. The LAN was connected to Hinet through TANET (which is provided by the ROC Education Ministry). Clients of RTDDS were con-nected to RTDDS over LAN in the laboratory.

The major performance metric was the stability of traf-ﬁcs, i.e. the QoS guarantee, from RTDDS to clients. Clients requested for 4096, 8192 and 16384 bytes of data transfer for every 20 ms from RTDDS (or service providers). When RTDDS was adopted, RTDDS acquired data from the ser-vice providers on behalf of clients and forwarded to clients according to the requirements of clients. We run the re-quests for 1000 times with or without RTDDS. We then take the results in the middle 500 samples to remove im-proper experimental factors. We also evaluated the over-heads of RTDDS, which was mainly the delay of data trans-missions from the receiving of data (from service providers) and the forwarding of data (from RTDDS). The overheads were measured ﬁve times and averaged.

4.2 Experimental Results

Figure 5. The distributions of data transmis-sions without RTDDS

Figure 5 shows the distributions of data transmissions for clients without RTDDS. In 20 ms, clients requested 4096, 8192 and 16384 bytes respectively. Figure 6 reports the re-sults of the same experiments with RTDDS. When clients

(7)

Figure 6. The distributions of data transmis-sions with RTDDS

Run 1 Run 2 Run 3 Run 4 Run 5 Average

Delay 2804 2684 2524 2784 2664 2692ms

Table 1. The overheads of RTDDS in transmis-sion delay

requested data through RTDDS, they always received a very stable transmission rate according to the requests of clients. When RTDDS was not adopted, the data transmission rates ﬂuctuated with a wide scale. During most of the experiment time, the rates could go up and down violently.

Table 1 shows the overheads of RTDDS, which was mainly the delay of data transmissions from the receiving of data (from service providers) and the forwarding of data (from RTDDS). The delay was about 2.5 seconds. We must emphasize that the delay only occurred when the service was first delivered. Once services were delivered, clients would no longer feel any delay. The delay could also be called start-up delay of services. It was the price paid for traffic regulation under RTDDS. The large fluctuation in the beginning of Figure 6 were due to the delay of data trans-missions, as shown in Table 1.

5. Conclusion

This paper proposes the design and implementation of a relaying-service system from service providers to front-end clients with QoS guarantees. RTDDS consists of a col-lection of machines, which collectively serve as relaying-service nodes to regulate network trafﬁc from the nodes to clients according to the requirements of each client. We consider Bin-Packing approximation algorithms to parti-tion workload among machines of RTDDS. We adopt the stack-based resource protocol (SRP) for autonomous

work-load scheduling on each machine. RTDDS is designed as a message-oriented distributed system which provides load balancing with a broker-based mechanism over JVM. We conducted a series of experiments to show the overheads in adopting the RTDDS solution and to demonstrate the capa-bility of RTDDS in regulating trafﬁc for clients.

RTDDS provides extended services over ordinary proxy servers in relaying data streams from service providers to front-end clients. For future research, we shall further ex-plore pulling services from service providers for clients with QoS supports.

References

[1] J. Alateras, T. Anderson, and J. Mourikis. OpenJMS User Guide. ExoLab Group, February 2002.

[2] T. P. Baker. A stack-based resource allocation policy for real-time processes. IEEE Real-Time Systems Symposium, pages 191–200, 1990.

[3] E. G. Coffman, J. M. R. Garey, and D. S. Johnson. Ap-proximation algorithms for bin packing: A survey. In D. Hochbaum, editor, Approximation Algorithms for NP-Hard Problems, chapter 2, pages 46–93. PWS Publishing Company, 1997.

[4] Z. Deng and J. Liu. Scheduling real-time applications in an open environment. IEEE Real-Time Systems Symposium, pages 308–319, December 1997.

[5] M. Hapner, R. Burridge, R. Sharma, J. Fialli, and K. Stout. Java Message Service Speciﬁcation. Sun Microsystems, 1.1 edition, April 2002.

[6] L. T. Kou and G. Markowsky. Multidimensional bin packing algorithms. IBM J. RES. Dev. 21, pages 443–448, 1977. [7] C. L. Liu and J. W. Layland. Scheduling algorithms for

multi-programming in a hard real-time environment. Journal of the Association for Computing Machinery, 20(1):46–61, January 1973.

[8] Object Management Group. Common Object Request Broker Architecture (CORBA/IIOP), 3.0.2 edition, December 2002. [9] P. W. Shor. How to pack better than best ﬁt: Tight bounds

for average-case on-line bin packing. Proceedings of the 32nd Annual Symposium on Foundations of Computer Sci-ence, pages 752–759, 1991.