US 6,003,062 AGrant

Iterative Algorithm for Performing Max Min Fair Allocation

Issue Date:1999-12-14

•20 Claims

•2 Drawing Sheets

Abstract

The present invention pertains to a method for providing service to entities. The method comprises the steps of receiving a first request for service by a server within a predetermined time from a first entity. Next there is the step of receiving a second request for service by the server within the predetermined time from a second entity. Then there is the step of reducing the service to be provided by the server to the first entity so the second entity can be provided service by the server within the predetermined time. The present invention pertains to a system for providing service. The system comprises N entities, where N is greater than or equal to 2. Each of the N entities require service. The system comprises a server which provides service to the N entities. Also, the system comprises a scheduler connected to the entities and the server. The scheduler provides service to the N entities by reducing the amount of service to at least one of the N entities from the server until all of the N entities receive their minimum amount of service.

Metadata

Assignee

FORE Systems, Inc.

Inventors

Martin G. Greenberg
Steven J. Schlick

Application Information

Application Number:US 8953538

Filing Date:1997-07-16

Priority Date:1997-07-16

Art Unit:278

Classifications

IPC:

H04Q 1104H04L 1256H04L 1226H04L 1224

Field of Search:

709370102;103;104;107;232;234;235;105230;231;391;395;232;234

Patent Drawings (2 sheets)

Description

FIELD OF THE INVENTION

The present invention is related to providing service to entities. More specifically, the present invention is related to providing service to N entities by reducing the amount of service to at least one of the N entities from the server until all of the N entities receive their minimum amount of service.

BACKGROUND OF THE INVENTION

In many applications, multiple entities have demands for a service or resource where the aggregate demand exceeds the total resources available. In such a situation, the goal is to allocate the available resources in a fair manner among the entities. Some systems, such as an ABR capable ATM adapter, require this allocation to be performed quickly and repeatedly due to the dynamic nature of the demands on the shared resource.

In the past, this task has been done in one of two basic ways; using implicit allocation or explicit allocation. Implicit allocation services each entity according to a policy, such as round-robin or weighted round-robin, and the shared resources are "allocated" as the entities use them during their turn to be serviced. Explicit allocation attempts to calculate using some criterion, such as proportional allocation or max-min fairness, the amount of resources to be provided to each entity which can then be used to determine when to service each entity.

The different methods of performing allocation vary in complexity of implementation, fairness, accuracy, and failure modes. Explicit allocation using the max-min fairness criterion is considered to be one of the best methods for performing this task, but it has been considered impractical to use due to the time to perform and complexity of the calculations required especially when the number of entities is "large". The algorithm presented provides a simple, quick method of performing an explicit max-min fair allocation and can be customized for a variety of applications.

SUMMARY OF THE INVENTION

The present invention pertains to a system for providing service. The system comprises N entities, where N is greater than or equal to 2. Each of the N entities require service. The system comprises a server which provides service to the N entities. Also, the system comprises a scheduler connected to the entities and the server. The scheduler provides service to the N entities by reducing the amount of service to at least one of the N entities from the server until all of the N entities receive their minimum amount of service.

The basic algorithm of the preferred embodiment produces a rate assignment for a given connection using a combination of some global and per connection information. Each time the set of connections is run through the allocation algorithm, the rate assignments are adjusted such that they quickly converge to a max-min fair allocation.

For situations, such as ATM network equipment, where there are requirements for handling different types of connections with different identifying parameters, prioritization of connections based on service class, or minimum rate guarantees the max-min fairness can be enhanced by adding branches to the decision process. Multiple service classes can be supported by simply selecting the appropriate parameter to use in the fairness algorithm based upon service class. Minimum requirements can be met by either using the fair share for resources left after meeting the minimum requirements or by having the fair share be bounded by (i.e. no less than) the minimum requirement. Similarly, higher priority connections' demands can met first and bypass the fairness algorithm altogether.

In addition to the flexibility available by adding branches to the decision tree, the basic algorithm contains three other points for customization. The most simple is to change the initialization value for the total available bandwidth to allow the use of this algorithm with whatever speed physical interface (OC3, OC12, etc. where OC3 is optical carrier 3 equivalent to a data rate of 155.52 Mb/sec. and OC12 is optical carrier 12 equivalent to a data rate of 622.08 Mb/sec.) desired. The other two points involve the movable ceiling which represents the current max-min fair share. The algorithm operates similarly to Newton's method for finding the solution to an algebraic equation in that it incrementally adjusts the ceiling (i.e. the solution to the problem) in a series of smaller and smaller steps until it reaches the fair share for the current set of bandwidth requests. The adjustments are made according to two equations, one for increasing the ceiling when there is free bandwidth available and one for decreasing the ceiling when a new demand exceeds the bandwidth currently available.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, the preferred embodiment of the invention and preferred methods of practicing the invention are illustrated in which:

FIG. 1 is a schematic representation of a system of the present invention.

FIG. 2 is a flow chart of the algorithm of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to the drawings wherein like reference numerals refer to similar or identical parts throughout the several views, and more specifically to FIG. 1 thereof, there is shown a system 10 for providing service. The system 10 comprises N entities 14, where N is greater than or equal to 2. Each of the N entities 14 require service. Each of the N entities 14 preferably require at least a minimum amount of service. The system 10 comprises a server 16 which provides service to the N entities 14. Also, the system 10 comprises a scheduler 18 connected to the entities 14 and the server 16. The scheduler 18 provides service to the N entities 14 by reducing the amount of service to at least one of the N entities 14 from the server 16 until all of the N entities 14 receive their minimum amount of service. Preferably, the N entities 14 receive a share of service equal to their minimum service plus a max-min fair share of the excess service available.

The scheduler 18 preferably includes a transmit scheduler. The scheduler 18 preferably also includes a bandwidth allocator 20 which controls the amount of service by the server 16 to the N entities 14 so each of the N entities 14 receives at least its minimum required amount of service. The scheduler 18 preferably increases the amount of service to entities 14 requesting service after an entity 14 receives the service the entity 14 has requested from the server 16.

The server 16 preferably includes a host 20 which writes desired traffic parameters for a virtual connection and the amount of requested bandwidth for the connection to the transmit scheduler 18. The server 16 preferably includes a host memory 22 for holding data packets 24 written by the host 20. The server 16 preferably includes a packet ready queue 24 for holding descriptors for the data packets 24 in the host memory 22.

With reference to FIG. 2, the present invention pertains to a method for providing service to entities. The method comprises the steps of receiving first request for service by a server within a predetermined time from a first entity. Next there is the step of receiving a second request for service by the server within the predetermined time from a second entity. Then there is the step of reducing the service to be provided by the server to the first entity so the second entity can be provided service by the server within the predetermined time.

The reducing step preferably includes the step of reducing the service to be provided by the server to the first entity while the second entity is waiting for service so the second entity can be provided service by the server within the predetermined time. Preferably, after the receiving the first request step, there is the step of providing service by the server to the first entity. After the reducing step, there is preferably the step of providing service by the server to the second entity. Preferably, after the reducing step, there is the step of providing a reduced amount of service to the first entity. The producing step preferably includes the step of reducing the service to be provided by the server to the first entity so the server can provide service required of it by the second entity. After the providing reduced service to the first entity step, there is preferably the steps of receiving a request for service by the server from a third entity who has a priority status that entitles the third entity to receive as much service from the server as the third entity needs.

After the receiving a request for service from the third entity step, there are preferably the steps of providing by the server all the service requested of it by the third entry. Then there is the step of reducing the amount of service provided by the server to the first and second entities by an amount necessary to provide all the service by the server requested of it by the third entity.

Alternatively, after providing the reduced service to the first entity step, there are preferably the steps of receiving a request from a third entity for service by the server which requires an amount of service from the server which is less than a second maximum amount of service available from the server. Then there is the step of providing service to the third entity by the server without reducing the amount of service provided by the server to the first and second entities.

Alternatively, after the step of providing service to the second entity, there is the step of increasing the amount of service provided by the server to the first entity. Before the increasing step, there is preferably the step of making available service that was provided by the server to the second entity. After the making available step, there is preferably the step of determining that there are not other requests for service by the server from entities other than the first entity which have not been satisfied.

Alternatively, after the receiving the second request step, there is preferably the step of receiving a second request for service which is less than the maximum share of service available by the server for the second entity. The receiving the second request step then preferably includes the step of receiving a second request for service which is less than the service available by the server for the second entity. The providing service by the server to the second entity step preferably then includes the step of providing the same amount of service to the second entity as the service requested of the server by the second entity.

Alternatively, the receiving the second request step preferably includes the step of receiving a second request for service which is more than the service available by the server for the second entity. The second request step preferably then includes the steps of receiving a second request for service with a minimum rate which is less than the service available to the second entity by the server. The step of providing service to the second entity then preferably includes the step of providing the service to the second entity at the service available to the second entity by the server. The second request step preferably then also includes the step of adjusting a maximum share of service available to the second entity by the server downward.

Alternatively, the receiving the second request step preferably includes the steps of receiving a second request for service with a minimum rate which is more than the service available for the second entity by the server. The providing service by the server to the second entity step preferably then includes the step of providing service to the second entity in an amount equal to the minimum rate. The second requesting step then preferably includes the step of adjusting a maximum share of service available to the second entity by the server downward.

Alternatively, the receiving the second request step preferably includes the step of receiving a second request for service which is greater than the maximum share of service available by the server for a second entity. The receiving the second request step preferably then includes the step of receiving a second request for service from the second entity which has a maximum share of service which is greater than the service available by the server for the second entity. The providing service by the server to the second entity step preferably then includes the step of providing service to the second entity at a share equal to the service available.

Alternatively, the receiving the second request step includes the step of receiving a second request for service from the second entity which has a maximum share of service which is less than the service available by the server for the second entity. The providing service by the server to the second entity step preferably includes the step of providing service to the second entity equal to the maximum share of service available by the server for the second entity.

In the operation of the preferred embodiment, FIG. 1 illustrates how the implementation of the algorithm (the Bandwidth Allocator 20) is connected to the remainder of the system 10 and the attached Host 20. The Interfaces between blocks have been labeled.

The Host 20 begins transmission by first writing the desired traffic parameters for a Virtual Connection (VC) to the Transmit Scheduler 19 (Interface 1). The host 20 writes the value of the Requested Bandwidth (ACR) for the connection and the Service Category (SC) to the Transmit Scheduler 19. The Host 20 then writes one or more Data Packets 24 to host memory 22 and then queues one or more descriptors to the Packet Ready Queue 25. The information in queues on Interface 2 includes the address, length and VC for the Data Packet(s) 24 in host memory 22.

The Transmit Scheduler 18 pulls the information from the Packet Ready Queue 25 (Interface 3; the same data contents as on Interface 2). If the Transmit Scheduler 19 determines that the VC for the Data Packet 24 is not currently Active, then a request is made on Interface 4 with the following parameters:

Opcode: Set to FIRST

ACRi+1: New value of ACR (requested bandwidth)

MCR: Miminum Cell Rate for the connection.

ACRi: Previous value of ACR

NCRi: Previous value of NCR

SC: Service Category for the connection (CBR, UBR or ABR)

use.sub.-- wmin: Per-VC state, set if the connection if the global NCR.sub.-- min is to be a lower bound for the NCR for the connection.

There is a single value returned on Interface 5:

NCRi+1: Output of the bandwidth allocator

Once the Transmit Scheduler 19 has the new NCR for the VC, the VC is set to segment cells at the rate NCR. At this rate, data is transferred from Data Packets 24 in host memory 22 (Interface 6) and sent to the ATM Network 26 as ATM Cells (Interface 7). The Transmit Scheduler 19 may request new allocations on Interface 4 by using the same arguments as listed before but using an Opcode parameter of CHANGE or FIXED. The Transmit Scheduler 19 may also give new values for ACRi+1 if the rate has changed due to feedback from the ATM Network 26. If a VC is to be deallocated, the Transmit Scheduler 18 sends a command on Interface 4 with an Opcode of DEALLOC.

Pseudocode

There are three service categories supported: CBR, ABR and UBR

CBR is distinguished in that the max-min algorithm is not applied to connections. Instead, the desired bandwidth is simply subtracted from TFB and allocate to the connection

UBR traffic does not necessarily have the available TFB as its upper limit. Instead, if the use.sub.-- wmin bit for the connection is set, then the minimum bandwidth for the connection is given by the WCR.sub.-- MIN register. Although if value of WCR.sub.-- MAX is less than WCR.sub.-- MIN, then WCR.sub.-- MAX is the ceiling for the assigned bandwidth.

ABR traffic has a guarantee in addition to those for UBR. If the rate of traffic for an ABR connection is less than or equal to TCR (Terminal Cell Rate), then the WCR for the connection is fixed to TCR. This rule ensure adequate scheduler bandwidth for ABR connections which are trying to reallocate rate from the network.

The bandwidth allocation for all connection is recalculated periodically for every "X" number of cells transmitted, and when the connection remains in the bandwidth deficit state (when the connection is not able to allocated at least WCR.sub.-- max in bandwidth). The bandwidth allocator is also invoked when an inbound b-RM cell results in a rate change for an ABR connection.

Definitions for the bandwidth allocator algorithm are the following:

CFB: Current Free Bandwidth, in units of cells/second. Initialized to line rate.

BWmax: Maximum value for assignment of NCR. Initialized to Line Rate.

BWinc: Additive increase for BW.sub.-- max (comparable to the "e1" parameter in the white paper)

BWdec: Additive decrease for BW.sub.-- max (comparable to the "e2" parameter in the white paper)

ACRi+1: New value of ACR (requested bandwidth)

NCRi+1: Output of the bandwidth allocator

MCR: Minimum Cell Rate for the connection.

ACRi: Previous value of ACR

NCRi: Previous value of NCR

BRNS: Bandwidth Deficit Count, number of channels which cannot allocate BW.sub.-- max due to limit in CFB

MBRS: Per-connection flag which indicates connection was not able to allocate BW.sub.-- max due to limits in CFB.

BRSO: Bandwidth Requests Satisfied and Open. Number of active channels which have successfully allocated at least BW.sub.-- max (comparable to the "m" parameter in the white paper).

SC: Service Category for the connection (CBR, UBR or ABR)

New Parameters for implementation:

opcode: Argument passed into algorithm describing the type of operation:

FIRST: First bandwidth request for the connection

UPDATE: Request new NCR for a previously allocated connection.

DEALLOC: Completely deallocate the connection's allocated bandwidth

FIXED: Fix the allocated bandwidth to the requested bandwidth

use.sub.-- wmin: Per-VC state, set if the connection if the global NCR.sub.-- min is to be a lower bound for the NCR for the connection.

nailed.sub.-- acr: State local to bandwidth allocation routine, indicates ACR for ABR connection was adjusted up to TCR.

TCR: Terminal Cell Rate for ABR connections.

BW.sub.-- ceil: Upper ceiling for BW.sub.-- max. Initialized to Line Rate.

NCR.sub.-- min: Selective minimum value for NCR.

var.sub.-- BWinc: Flag which indicates variable mode is used for increase of BW.sub.-- max.

var.sub.-- BWdec: Flag which indicated variable mode is used for decrease of BW.sub.-- max.

Following is the pseudocode algorithm for bandwidth allocation of UBR, ABR and CBR:

Before leaving the bandwidth allocation routine, the value of BW.sub.-- max is adjusted:

If the current CFB value is positive and the bandwidth deficit count is zero, then BW.sub.-- max is increased. Else if the bandwidth deficit flag for the connection being serviced is set, then BW.sub.-- max is decremented. Otherwise, BW.sub.-- max remains the same. BW.sub.-- max cannot be increased above the limit imposed by BW.sub.-- ceil.

The var.sub.-- BWinc and var.sub.-- BWdec flags control the operating mode for the BW.sub.-- max increase and decrease amounts. If either flag is set, the corresponding delta for BW.sub.-- max is proportional with to the number of active connections which have a NCR of at least BW.sub.-- max.

Algorithm Operation Example

For the pseudocode presented above, let's observe the algorithm in operation using the following connections:

VC #1: UBR connection, ACR=600 Mbps, use.sub.-- wmin=TRUE

VC #2: UBR connection, ACR=600 Mbps, use.sub.-- wmin=TRUE

VC #3: UBR connection, ACR=100 Mbps, use.sub.-- wmin=TRUE

VC #4: CBR connection, ACR=50 Mbps

VC #5: ABR connection, ACR initially is 500 Mbps (reduced later), use.sub.-- wmin=FALSE, MCR=9.37 Mbps

The VC's are allocated over the course of the run, rescheduled on occasion, then deallocated before the end of the run. The initial global parameters for the algorithm are:

Line.sub.-- Rate=600 Mbps (megabits per second)

CFB=Line.sub.-- Rate

BW.sub.-- max=BW.sub.-- ceil=Line.sub.-- Rate

NCR.sub.-- min=Line.sub.-- Rate/600 Mbps=18.75 Mbps

BW.sub.-- inc=BW.sub.-- dec=Link.sub.-- Rate/8=75 Mbps

var.sub.-- BWinc=var.sub.-- BWdec=TRUE

BRNS=BRSO=0

NCR and MBRS for each connection is zero

Table A below shows the sequence of operations which are sent to the bandwidth allocator (indexed by Operation Number). The Operation Type is either ALLOC (allocate new connections), RESCH (rescheduled existing connection), FIXED (schedule connection at fixed NCR=ACR), or DEALC (deallocate bandwidth for connection). The VCI associated with the operation is listed along with its current ACR and the new NCR value assigned for the VC by the allocator. It also lists the change if any in the per-VC MBRS state. To the right of the dark bar in the table is the current global state for the bandwidth allocator: the BRNS and BRSO counts, the BW.sub.-- max limit, and CFB (Current Free Bandwidth).

Some of the highlights of the operation example are:

At op#1, VC #1 is allocated 600 Mbps of the Line Rate

At op#4, VC #2 is allocated the NCR.sub.-- min value (18.75 Mbps)

By op#12, the BW.sub.-- max threshold has been reduced to 300 Mbps, and VC#1 and VC#2 are sharing the Link Rate equally.

At op #13, VC #3 is allocated NCR.sub.-- min (18.75 Mbps)

By op#22, the BW.sub.-- max has been reduce to 250 Mbps so that VC #3 has all 100 Mbps of its requested bandwidth, and VC #1 and #2 share the remaining 500 Mbps equally,

At op#26, CBR connection VC #4 is allocated its ACR of 50 Mbps immediately.

By op#32, the BW.sub.-- max threshold has been reduced so that VC #3 and #4 have their requested bandwidths (150 Mbps combined), while connections VC #1 and #2 share the remaining 450 Mbps equally.

At op#35, VC #2 is deallocated. By op#39, VC #1 has claimed all of the bandwidth freed by the deallocation (NCR for VC #1 now 450 Mbps)

At op#54, ABR connection VC #5 is allocated its MCR of 9.375 Mbps.

By op#66, VC #1 and #5 are sharing the available bandwidth of 550 Mbps (50 Mbps is still allocated to CBR connection #3).

At op#68, VC #5 reduces its NCR to 100 Mbps. By op#71, VC #1 has reclaimed the bandwidth freed by VC #5.

At op#76, VC #5 reduces its rate to 1 cell/sec (0.000424 Mbps). Since the TCR (Terminal Cell Rate) for an ABR connection is 10 cells/sec, the NCR for the connection is fixed to 0.00424 Mbps.

By op#79, VC #1 has reclaimed the bandwidth freed by VC #5, increasing its NCR to 550 Mbps.

At op#81, VC #5 fixed its rate to 50 Mbps. By op#86, VC #1 has reduced its rate to 500 Mbps (with VC #5 has 50 Mbps and VC #4 at 50 Mbps).

During op#89 to 93, VC #5 deallocates its bandwidth, then VC #4. In both cases, VC #1 reclaims the freed bandwidth.

At op#96, VC #1 deallocated. CFB returns to its initial value of 600 Mbps and BRNS and BRSO return to zero.

To further describe the algorithm in its various forms, additional examples are provided. The first is a comparison of the results from the use of various allocation schemes, and the other is the output of a sample simulation run.

Table B gives a sample set of connections among whom bandwidth needs to be divided. For purposes of the example, the total bandwidth available is 400 and the bandwidth request by each virtual connection (VC) is listed in the table at the very bottom. The last two columns of the table give the fairness metric for each algorithm and the amount of bandwidth that went unused due to the algorithm assigning more bandwidth than was requested. The fairness metric is calculated by dividing the granted bandwidth by the requested bandwidth for each VC, with a maximum value of 1.00, and then calculating the geometric mean (the geometric mean of a set of n values is calculated by taking the n.sup.th root of the product of the n values) of the 10 values.

The first row of Table B represents proportional allocation. If the sum of the requested bandwidths is less than the link rate, each connection is assigned its requested bandwidth. In the case of oversubscription, i.e. the total is more than the link rate, each connection is assigned its requested bandwidth scaled down by the ration of the link rate divided by the total requested bandwidth. This allocation scheme is not always explicitly implemented. By always granting the requested rate and enforcing a maximum aggregate rate, proportional allocation can be done implicitly. One such mechanism is weighted round-robin queuing where connections of each bandwidth are grouped and the groups are served with a frequency proportional to their rate. The second row is the allocation resulting from a pure round robing service. Each connection gets an equal portion of the link rate, regardless of requested bandwidth in contrast to weighted round robin which takes the relative rates into account. Lastly, the max-min fair allocation is shown in the last row.

The proportional allocation makes full use of the available bandwidth, but it has one major disadvantage. Once oversubscription occurs, not a single connection, no matter how small its request, gets the full amount for which it asked. This causes a poor fairness metric for this scheme especially in cases where the oversubscription is by a significant amount.

Pure round robin can give a wide variety of fairness and wasted bandwidth results. In this example, since a number of connections had requested bandwidth less than 1/10 the link rate, they received their request (and more) which improved the fairness metric by more than 70% over proportional allocation. However, since those same connections that improved the fairness were actually requesting less than 1/10 of the link rate, there is a substantial amount of unused bandwidth.

The max-min scheme satisfies the lower requests like the round robin, but it does not waste the bandwidth. The combination of the two yields the highest fairness metric value and maintains zero wasted bandwidth.

The sample run of the simulator is found in the Appendix. The output represents the first 50 cell times of a SAR whose transmitter is using the max-min algorithm. Although the algorithm does not reach the true steady state until roughly cell time 100, the allocation of bandwidth has reached the point where no connection is more than 6.5% off from its steady state allocation.

The situation being simulated is as follows: 4 connections, number 0, 3, 5 and 7) are low priority (UBR) connections requesting the full link rate of 353207 cells per second; connection 2 is a high priority (CBR) connection requesting 20% of the link (70640 cells/second); and the other three connections (numbers 1, 4 and 6) are also CBR connections, but with requests of 10% (35320 cells/second) each. The high priority connections should each receive exactly their requested bandwidth once the connection is opened, and in the steady state the low priority connections should each receive 12.5% of the link rate or 44150 cells/second.

Although the invention has been described in detail in the foregoing embodiments for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that variations can be made therein by those skilled in the art without departing from the spirit and scope of the invention except as it may be described by the following claims.

Claims

What is claimed is:

1. A method for providing service to entities comprising the steps of: receiving a first request for service by a server within a predetermined time from a first entity; producing a rate assignment to the first entity; receiving a second request for service by the server within the predetermined time from a second entity; producing a rate assignment to the second entity; adjusting the rate assignment to the first entity so the service to the first entity and the second entity; allocating explicitly service to the second entity from service originally provided by the server to the first entity based on max-min fairness; reducing the service to be provided by the server to the first entity while the second entity is waiting for service so the second entity can be provided service by the server within the predetermined time; receiving a request for service by the server from a third entity who has a priority status that entitles the third entity to receive as much service from the server as the third entity needs; producing a rate assignment to the third entity; providing by the server all the service requested of it by the third entity; adjusting the rate assignment to the first entity and to the second entity so the service to the first entity, second entity and the third entity converge to a max-min fair allocation; reducing the amount of service provided by the server to the first and second entities by an amount necessary to provide all the service by the server requested of it by the third entity; and receiving a fourth request for service from the second entity with a minimum rate which is more than the service available for the second entity by the server; and providing service to the second entity in an amount equal to the minimum rate.

2. A method as described in claim 1 including after the receiving the first request step, there is the step of providing service by the server to the first entity.

3. A method as described in claim 1 including after the reducing step, there is the step of providing service by the server to the second entity.

4. A method as described in claim 3 including after the reducing step, there is the step of providing a reduced amount of service to the first entity.

5. A method as described in claim 3 including after the step of providing service to the second entity, there is the step of increasing the amount of service provided by the server to the first entity.

6. A method as described in claim 5 including before the increasing step, there is the step of making available service that was provided by the server to the second entity.

7. A method as described in claim 6 including after the making available step, there is the step of determining that there are no other requests for service by the server from entities other than the first entity which have not been satisfied.

8. A method as described in claim 3 wherein the receiving the second request step includes the step of receiving a second request for service which is less than the maximum share of service available by the server for the second entity.

9. A method as described in claim 8 wherein the receiving the second request step includes the step of receiving a second request for service which is less than the service available by the server for the second entity.

10. A method as described in claim 9 wherein the providing service by the server to the second entity step includes the step of providing the same amount of service to the second entity as the service requested of the server by the second entity.

11. A method as described in claim 8 wherein the receiving the second request step includes the step of receiving a second request for service which is more than the service available by the server for the second entity.

12. A method as described in claim 11 wherein the second request step includes the steps of receiving a second request for service with a minimum rate which is less that the service available to the second entity by the server; and wherein the step of providing service to the second entity includes the step of providing the service to the second entity at the service available to the second entity by the server.

13. A method as described in claim 12 wherein the second request step includes the step of adjusting a maximum share of service available to the second entity by the server downward.

14. A method as described in claim 11 wherein the second requesting step includes the step of adjusting a maximum share of service available to the second entity by the server downward.

15. A method as described in claim 3 wherein the receiving the second request step includes the step of receiving a second request for service which is greater than the maximum share of service available by the server for the second entity.

16. A method as described in claim 15 wherein the receiving the second request step includes the step of receiving a second request for service from the second entity which has a maximum share of service which is less than the service available by the server for the second entity; and the providing service by the server to the second entity step includes the step of providing service to the second entity equal to the maximum share of service available by the server for the second entity.

17. A system for providing service comprising: N entities, where N is greater than or equal to 2, each of the N entities require service; a server which provides service to the N entities, said server includes a host which writes desired traffic parameters for a virtual connection and the amount of requested bandwidth for the connection to the transmit scheduler; and a transmit scheduler connected to the entities and the server, said scheduler providing service to the N entities by reducing the amount of service to at least one of the N entities from the server until all of the N entities receive their minimum amount of service, said scheduler includes a bandwidth allocator which controls the amount of service by the server to the N entities so each of the N entities receives at least its minimum required amount of service, said scheduler including means for explicitly allocating service to the N entities by reducing service originally provided by the server to at least one of the entities until all of the N entities receive their minimum amount of service and converge to a max-min fair allocation based on max-min fairness according to a decision tree and a movable ceiling which represents a current max-min fair share, with the ceiling increasing when there is free bandwidth available and with the ceiling decreasing when demand from the first and second entities exceeds bandwidth currently available from the server.

18. A system as described in claim 17 wherein the server includes a host memory for holding data packets written by the host, and a packet ready queue for holding descriptors for the data packets in the host memory.

19. A system as described in claim 18 wherein each of the N entities require at least a minimum amount of service.

20. A system as described in claim 19 wherein said scheduler increases the amount of service to entities requesting service after an entity receives the service the entity has requested.

Patent Citations (18)

Patent	Date	Inventor
US5313454	1994-05-01	Bustini et al.
US5479404	1995-12-01	Francois et al.
US5533020	1996-07-01	Byrn et al.
US5546377	1996-08-01	Ozveren
US5633859	1997-05-01	Jain et al.
US5675576	1997-10-01	Kalampoukas et al.
US5689508	1997-11-01	Lyles
US5737313	1998-04-01	Kolarov et al.
US5745697	1998-04-01	Charny et al.
US5748901	1998-05-01	Afek et al.
US5754530	1998-05-01	Awdeh et al.
US5793747	1998-08-01	Kline
US5805577	1998-09-01	Jain et al
US5805599	1998-09-01	Mishra et al.
US5831971	1998-11-01	Bonomi et al.
US5844890	1998-12-01	Delp et al.
US5864538	1999-01-01	Chong et al.
US5917822	1999-06-01	Lyles et al.

Abstract

Description