in accordance with one embodiment of the present invention , a 3 - piece linear service curve is transformed into a two - piece linear curve to enable concurrent attainment of traffic class delay priority and long - term bandwidth allocation on the one hand , and a computationally efficient algorithm for representing and processing the transformed service curve , on the other . in accordance with this algorithm , the computation of a new deadline parameter , as specified in the update_ed and update_d pseudo code functions defined by i . stoica , h . zhang , and t . s . e . ng , in an article entitled “ a hierarchical fair service curve algorithm for link - sharing , real - time and priority service ”, proc . acm sigcomm , 1997 , the content of which is incorporated herein by reference in its entirety , is modified such that each traffic class k is configured with a fixed offset called u_i in order to achieve the transformation . the fixed offset value is included as a term that is added to the new deadline d_i where it is updated . the data structures that maintain and manage service curves of the present invention are realized with those used in connection with 2 - piece linear curves . the algorithm of the present invention thus retains the computational efficiency of the hfsc algorithm . an exemplary pseudo - code of the algorithm is shown in fig1 . fig1 shows a transformed ( shifted ) two - piece linear service curve 1100 used in accordance with the algorithm of the present invention . such a shifted linear service curve supports both two - piece linear convex and two - piece linear concave curves , where in both cases the first segment is coincident with the origin . furthermore , a linear service curve in accordance with the present invention , referred to herein as a shifted concave curve , includes three linear segments , namely a first segment 1102 that is coincident with the x - axis and passes through the origin , a second segment 1104 with slope m 1 & gt ; 0 beginning at time x 1 = u_i , and a third segment 1106 with slope m 2 & gt ; 0 beginning at time x 2 . by adding the offset parameter u_i to the deadline computation , the algorithm causes the scheduler to emulate the shifted concave curve for the purposes of the real - time service request scheduling decision . the modification achieved by the algorithm of the present invention thus enables the realization of the service curve framework of fig9 . fig1 shows a family of service curves 1202 , 1204 , 1206 , 1208 , 1210 , 1212 and 1214 that decouple delay and bandwidth requirement by using a set of shifted concave curves . accordingly , the entire bandwidth of the link can be allocated to the non - zero service curve segments in each region . this means that when each of the classes that correspond to their respective service curves are active , all of the bandwidth is utilized thus preventing a lower - priority class from using otherwise excess bandwidth . in some embodiments , the service curves are automatically computed based on high level policy parameters specified by the network operator or user . in this framework , the operator assigns each traffic class a delay priority category from 1 to m , where m is the total number of priority categories . each delay priority category has an associated burst parameter , t_ 1 , . . . t_m , where t_k defines the amount of time classes in delay priority category k are allowed to pre - empt traffic from classes in delay priority categories k + 1 , k + 2 , . . . m , upon transitioning from an inactive to an active status . the sequence of t_ 1 , . . . t_m defines a partition of the x - axis into adjacent non - overlapping regions at x 1 = t_ 1 , x 2 = t_ 1 + t_ 2 , . . . representing the m delay priority categories available to traffic classes . in some embodiments of the present invention , the values t_ 1 , . . . , t_m are specified by the network operator . in other embodiments , the values could be pre - configured using heuristics or design calculations . parameter , t_k corresponds to the amount of time required to transmit a number of average size packets over the link being managed . this value is typically small to avoid starving out lower priority classes for extended periods of time , but can be made larger if the environment or design considerations call for such a configuration . the service curve abstraction feature provides a precise mechanism by which delay priority is defined because it allows the specification of the period in accordance with which a given class has priority over another , while both classes are active . after the expiration of this period , the two classes share bandwidths according to their respective bandwidth guarantees . when one or both of the classes go idle , and then become active , the preemption can take place once again as allowed by the service curve guarantees . the delay priority regions can have intuitive names to maintain an easy and intuitive end user interface and setup process . for example , the following nomenclature could be adopted for the various delay priority regions : accordingly , delay priority region 1 may be assigned for real - time traffic like voip or video conferencing . delay priority region 2 may be assigned for interactive traffic like a terminal session , a remote login , or a market trading application . delay priority region 3 may be assigned for business critical traffic like important file transfers or e - mail traffic . delay priority region 4 may be assigned for normal traffic like web browsing of internal application servers . delay priority region 5 may be assigned for low priority traffic like web browsing of external internet sites , or low - priority replication traffic . this listing of possible delay priority regions is merely illustrative and is not meant to limit the scope of this disclosure . it is understood that other naming conventions and practices may be used . with the delay priority categories defined in such a fashion , traffic classes can be assigned to the various categories in an intuitive manner . a network operator thus does not have to figure out all of the x - axis points at which the various service curves must fall . instead , the network operator merely specifies that a traffic class is a real - time class or a low - priority class and so forth , while still enjoying all the rigors of the underlying service curve scheduling model . as an example , assume that a voip traffic class is assigned to the realtime region , while a file transfer class is assigned to the normal region . the voip traffic might be guaranteed 1 mb / s while the file transfer class is guaranteed 2 mb / s . if it is then assumed there is only voip and file transfer traffic flowing over the network , and provided the offered load of the voip traffic remains less than 1 mb / s then voip packets will always be serviced before file transfer packets . more specifically , to configure a qos policy , the operator assigns a bandwidth guarantee and a delay priority category number to each traffic class . assume there are n traffic classes , 1 , 2 , . . . , n . assume that the bandwidth guarantee for traffic class k is designated with b_k , where k = 1 , . . . , n , and the priority category for traffic class k is designated with p_k . further assume that t_k , the burst parameter , defines the amount of time classes in delay priority category k are allowed to pre - empt traffic from classes in delay priority categories k + 1 , k + 2 , . . . m , upon transitioning from an inactive to an active status . as described above , the sequence of t_ 1 , . . . t_m defines a partition of the x - axis into adjacent non - overlapping regions at x 1 = t_ 1 , x 2 = t_ 1 + t_ 2 , . . . representing the m delay priority categories available to traffic classes . note that p_k is in the set { 1 , . . . , m }. upon receiving input or commands via a user interface from the network operator , a management process computes n service curves , one for each traffic class , and finally configures a service curve scheduler with the computed service curves . each shifted concave service curve is represented by the 4 - tuple ( x 1 , x 2 , m 1 , m 2 ). the management process computes these parameters for each traffic class . the service curve of a class k is denoted herein by ( x 1 ( k ), x 2 ( k ), m 1 ( k ), m 2 ( k )). an efficient algorithm to compute these service curve parameters for each class is illustrated in fig1 . the algorithm assumes as input the number of classes , the bandwidth guarantee of each class , the delay category of each class , the number of delay categories , the burst size ( in time ) of each delay category , and the rate of the underlying link being managed . from these input parameters , the algorithm computes a service curve for each class . the process via which input values are obtained via a user interface are described further below . once these shifted concave service curves have been computed , they can be configured in a system implementing the algorithm of the present invention by un - shifting each of the shifted concave curves to create a normal concave curve coincident with the origin along with determining the delay offset u_k for each traffic class k = 1 , . . . , n . assume that the parameters for the un - shifted , two - piece curves are referred to as x ′( k ), m 1 ′( k ), and m 2 ′( k ) for each traffic class k . accordingly , x ′( k ) is the x - offset of the break in the two - piece linear curve , m 1 ′( k ) is the slope of the first segment of the curve coincident to the origin , and m 2 ′( k ) is the slope of the second segment of the curve beyond x ′( k ). for each class , these additional parameters can be computed as follows : one embodiment of the present invention provides an operator of a networking device an intuitive mechanism and user interface for manipulating and configuring qos policies that are automatically mapped onto service curves and configured into a service curve scheduler . rather than expose the service curve definitions to the operator , which would be overly complex and difficult to understand , the operator can express qos policies in terms of bandwidth allocations and delay priorities and have the system automatically generate the service curves to implement those polices . herein , the process of translating high level administrative policies and parameters into service curves is called service curve mapping . fig1 shows a high level arrangement of how a network operator interacts with a system , in accordance with one exemplary embodiment of the present invention . the operator manipulates a user interface 1400 , that may be a graphical interface , a command - line interface , or the like to create , delete , and otherwise configure traffic classes and the various parameters associated with such classes . such an interface may be embedded in a networking device , e . g ., as a web browser , or a command - line interface available over , e . g ., an ssh login , or it may be a separate software running on a management console and interacting with the networking device over the network . the user interface 1400 is in communication with a management process block 1405 that accepts input from the user , performs various transformations and computation as described herein to generate service curve specifications and so forth . the management process block 1405 can also provide feedback to the user interface 1400 to indicate back to the user ( operator ) the status of the configuration actions and the state of the managed networking device . the management process block 1405 configures the desired service curves into a service curve scheduler 1410 that may be embedded in a networking device . in accordance with another embodiment of the present invention , a user interface enables the network operator to manage a service curve scheduler . the user interface provides a means by which bandwidth and priority levels are specified and the service curves required to meet those bandwidth and priority levels are automatically calculated without requiring user aid by the management process . fig1 illustrates a possible user interface 1500 in accordance with one embodiment of the present invention . as shown in fig1 , the network operator may enter the parameters for a traffic class , namely , a minimum bandwidth and a delay priority category . the user interface includes a type - in box 1501 for the class name , a type - in box 1502 for the bandwidth guarantee , and a drop - down menu 1503 for the delay priority category , which includes a drop - down list of options 1504 , as well as buttons to save 1506 or abort 1505 the edits . the list of priority categories can either be built into the system a priori or it could be configured elsewhere as part of the process by which the network administrator configures qos and / or cos policies . a class name is assigned to the traffic class for easy identification . separate traffic classification rules are specified elsewhere to dictate how network packets are mapped onto classes using any one of a number of well known techniques . the “ save ” and “ cancel ” buttons are used to save or abort the edits . after entering the parameters via the user interface , and clicking the save button , the contents are communicated to the management process , which then carries out the computations described here in to manipulate an underlying service curve scheduler &# 39 ; s configuration . fig1 shows a user interface 1600 for creating and configuring priority categories , in accordance with one embodiment of the present invention . a type - in box 1601 is provided for the category name . type - in boxes for the burst size for of the category are entered either as a time parameter 1602 , e . g ., in milliseconds , or as a number of packets parameter 1603 . alongside either of these two type - in boxes are radio - button style check boxes allowing the operator to select the preferred specifications . while service curves are based on time values , a time value can be computed from a number of packets specification by taking the average packet size and multiplying be the link rate , yielding a good approximation for a burst size parameter . elsewhere the operator may define an ordering of the delay priority categories . this could be presented as an ordered list with an up and down button next to each entry to move its place in the list . alternatively , each category may simply be given a rank number and the categories could be ordered by ranking . the rank could be obtained from the user by extending the box in fig1 . other user interfaces may be available to delete classes or delete priority categories . the following is a description of a scheme for influencing how the link sharing hierarchy is configured in accordance with another embodiment of the present invention . by default , a simple hierarchy can be adopted whereby all of the classes are arranged in a flat structure such that each class is a child of the root class representing the entire link bandwidth . such a scheme is illustrated in fig1 . in accordance with this scheme , when a class does not utilize its full allocation of bandwidth , the excess bandwidth is allocated to other active classes in proportion to the weights defined by m2 parameters of the service curve of each of active class , as in weighted fair queuing . in accordance with the another embodiment , when excess bandwidth is available to the scheduler , i . e ., when all of the service curve guarantees have been achieved and yet there is additional link capacity available , then the excess bandwidth is apportioned in proportion to the long - term bandwidth guarantees of the traffic classes , i . e ., the m1 parameters of all the active service curves . however , there is no need to couple the link sharing logic to the real - time service curve guarantees , and a separate data structure may be employed to represent the link sharing polices . in the instant process , each node in the class hierarchy maintains a virtual time that represents the normalized amount of service that the corresponding class has received , independent of the real - time service curve . the process attempts to minimize the discrepancies between the virtual times of different nodes to effect sharing . since the virtual time manipulation can be managed independently from the real - time service curve scheduling guarantees , a parallel class hierarchy may be utilized to the represent the link sharing schema . in a more detailed embodiment , the algorithm of the present invention described herein may be further adapted to specify the link sharing policies separately from the real - time service guarantees , and optionally to present this in the user interface as a separate policy specification for controlling the apportionment of excess bandwidth . further , since the real - time guarantees derive exclusively from the service curves of leaf classes and since the link sharing policies derive from the hierarchical arrangements of internal nodes in the class tree , these specifications can be separated to simplify configuration by the network operator . a user interface may present the user with an option to create sharing classes and specify the parent - child relationships among the sharing classes . each traffic class , e . g ., as defined by fig1 , would further be designated as a member of a sharing class . each sharing class would be assigned a fraction of the link bandwidth , or a fixed amount of the link bandwidth . for example , fig1 depicts a class hierarchy that includes six leaf classes and three sharing classes called “ marketing ”, “ engineering ”, and “ accounting ”. for the purposes of link sharing , the three sharing classes are assigned percentages of the root class that represents the entire link , in this case 25 % for marketing , 50 % for engineering , and 25 % for accounting . in some other examples , the service curves rather than percentages for link sharing may be used . as is understood , a percentage of link bandwidth is simply a single piece linear service curve coincident with the origin . continuing with the example of fig1 , when spare bandwidth is available , it will be allocated such that the overall use of the link achieves these sharing percentages . for example , if there were no marketing traffic present but there was a sustained load of engineering and accounting traffic , then excess bandwidth would be allocated such that engineering received ⅔ of the link bandwidth ( i . e ., ½ /( ½ + ¼ )) and accounting would receive ⅓ of the link bandwidth ( i . e ., ¼ /( ½ + ¼ )). in a further embodiment , the network operator is relieved of the burdensome task of specifying service curve parameters and a link sharing hierarchy through automation . as in the previous technique for service curve mapping for the real - time traffic classes , service curve schedulers might include a scheme for automatically computing a link sharing hierarchy from operator defined policies . in one such technique , each of the traffic class definitions that the operator specifies , as shown for example in fig1 , is augmented to include a named bandwidth sharing category . in this approach , each of the named sharing categories is guaranteed to obtain an equal share of the bandwidth such that provided all of the real - time service curves are guaranteed , then any remaining bandwidth will be allocated to classes in a fashion that causes the sharing categories to have equal bandwidth . for example , in fig1 , there are three classes a , b , and c . classes a and b are assigned to sharing category s 1 and class c is assigned to sharing category s 2 . further suppose the bandwidth guarantee of class a is 80 % of the link , class b is 15 % of the link , and class c is 5 % of the link . if all three classes are active , the scheduler apportions the link bandwidth according to the class guarantees . but suppose only classes b and c are active . in this case , the scheduler will allocate 50 % of the bandwidth to class b and 50 % of the bandwidth to class c because of the sharing policy . suppose instead classes a and c are active while class b is idle . in this case , the scheduler will allocate the guaranteed 80 % of the link bandwidth to class a , as guaranteed by the service curve , and allocate the remaining 20 % to class c . in this case , as the algorithm attempts to minimize the discrepancy between the sharing goal ( 50 / 50 ) and the service guarantee ( class a gets 80 % of the link ), it allocates all of the excess to class c . in accordance with another exemplary embodiment for mapping sharing policies onto a link sharing class hierarchy , the sharing classes are arranged as in fig2 . in this embodiment , bandwidth is shared according to a priority order . here it assumed there are l sharing priority levels and each traffic class is assigned one of the sharing priority levels , e . g ., by modifying the class specification from fig1 to include a sharing priority level . to construct the hierarchy , there are l sharing classes s_ 1 , s_ 2 , . . . , s_l , that form sharing category 1 , and l − 1 additional sharing classes x_ 1 , x_ 2 , . . . , x ( l − 1 ) that form sharing category 2 . sharing class s_ 1 is assigned 90 % of the link bandwidth and x_ 1 10 % of the link bandwidth . s_ 2 is assigned 90 % of x_ 1 &# 39 ; s bandwidth ( or 9 % of the total ) while x_ 2 is assigned 10 % of x_ 1 &# 39 ; s bandwidth ( or 1 % of the total ). this pattern repeats . then , each traffic class that is assigned to sharing level k is configured as a child of sharing class s_k . given this arrangement , when there is unallocated service , the traffic classes in sharing category 1 are serviced such that they receive 99 % of the link bandwidth . once this is achieved , any excess service is provided to the classes in sharing category 2 , and so forth . if on the other hand , the classes in sharing category 1 are not active , then excess service will be apportioned to sharing category 2 until those classes receive 99 % of the link rate , and so forth . in this fashion , excess bandwidth is allocated in priority order within a factor of 1 %. in another embodiment for implementing link sharing , the network operator configures each traffic class to refer to another traffic class . with respect to the first traffic class , the second traffic class is called an “ overflow class ”. the design goal is that when a given class does not use all of its guaranteed service , the excess service is distributed to the overflow class first . if the overflow class does not utilize the service , then the excess is further distributed across all active classes in proportion to their bandwidth guarantees as in weighted fair queuing . if no overflow class is specified for a given traffic class , then excess service from that class is distributed in proportion to their bandwidth guarantees as in weighted fair queuing without first being allocated to an overflow class . this scheme is further described below . instead of allowing excess service to flow up and down the link sharing hierarchy , as in hfsc and cbq , the link sharing tree is replaced with a link sharing directed acyclic graph ( i . e ., dag ), where the directionality of each edge is incorporated in an alternative link sharing algorithm . in this model , excess service can flow only in the direction of a directed edge . each time a class is serviced , i . e ., the scheduler transmits a packet from the class , then the virtual times of each class along the tree from the leaf class to the root are updated as in the original process . since there is now a dag in place of a bidirectional tree , the new process requires that there be a set of directed edges from the leaf class through zero or more internal sharing classes , to the root . conversely , a different set of directed edges flow from the root down the dag to reach the leaf classes . when the scheduler decides to transmit a packet according to the link sharing rules , instead of traversing down the tree along any of the tree edges to find the earliest virtual time , the modified process follows only the directed edges that point downward toward the leaf classes . in order to configure such a link sharing , a dag is computed , in turn , from the traffic class configurations , which includes information about the overflow relationships . this can be accomplished as follows . for each class that is the target of an overflow relationship , a sharing class is allocated as the parent of that class where a directed edge points from the sharing class to the leaf class , but not vice versa . in addition , for each class that refers to the overflow class under discussion , there is a directed edge from each leaf class to the sharing class created for that overflow class . the service curve for the sharing class is a line traversing the origin with slope equal to the sum of the classes that point to the corresponding overflow classes . in addition , there is a directed edge from the root of the class hierarchy to the sharing class and vice versa . finally , for each class that is not an overflow class for any other class , there is a directed edge from the root to that class and vice versa . this completes the construction of the internal nodes of the sharing class . when operated upon by the process described above , the desired link sharing outcome is obtained . while it is presumed herein that the service curve framework applies to traffic aggregates often called a traffic classes , this terminology is adopted for the purposes of exposition and is not meant to limit the scope of this disclosure as it should be obvious to one of ordinary skill in the art upon reading this disclosure that service curves could be applied to any subset or stream of network traffic including , for example , individual transport connections , application sessions , network flows , and so forth , as well as any combination thereof . the above embodiments of the present invention are illustrative and not limiting . various alternatives and equivalents are possible . other additions , subtractions or modifications are obvious in view of the present disclosure and are intended to fall within the scope of the appended claims .