A network is described herein which includes a node and a downstream node where the node is capable of altering a Quality of Service (qos) class of one client (packet) which is associated with a plurality of clients (packets) in a manner such that when the downstream node receives and processes the altered client and the associated clients it will not reorder the altered client and the associated clients.
|
1. A method for eliminating the reordering of a plurality of packets when a Quality of Service (qos) class is altered for one of the packets, said method comprising the steps of:
marking, at a first node, said altered packet with an indicator that indicates an old qos class and a new qos class of said altered packet;
upon receiving said altered packet at a second node, checking the indicator in said altered packet;
queuing, at said second node, said altered packet in the old qos class and said remaining plurality of packets in the old qos class;
allocating, at said second node, a proxy packet in the new qos class;
once the proxy packet is scheduled to be serviced at said second node, servicing a head-of-line packet from said remaining plurality of packets queued in the old qos class as being in the new qos class instead of servicing and sending the proxy packet to a third node; and
marking, at said second node, said head-of-line packet with an indicator that indicates the old qos class and the new qos class of said head-of-line packet before sending said head-of-line packet to the third node.
2. The method of
4. The method of
6. The method of
|
1. Field of the Invention
The present invention relates to a quality of service (QoS) queuing system and a method for queuing clients (packets) in a manner that eliminates the reordering of the clients even after a QoS class of one of the clients is altered (promoted/demoted).
2. Description of Related Art
Mechanisms that provide various levels of QoS use schedulers and queues to offer privileged treatment or services to clients (jobs) that request those services. Clients can vary from rental car customers waiting to be served in various queues depending on their membership level, to processes waiting to be executed on a computer . . . to packets belonging to various QoS classes waiting to be serviced by a router in a network.
In queuing systems, clients with higher precedence classes have higher service rates or get serviced before the clients with lower precedence classes. The privilege given to clients with higher precedence classes causes a relatively shorter waiting time for them when compared to clients with lower precedence classes. As a result, the clients in the higher precedence classes in general leave the system earlier than the clients in the lower precedence classes. To accomplish this, the queuing system often reorders the sequence of clients to service the higher precedence clients before the lower precedence clients.
In some cases, when there are no clients with higher precedence classes waiting to be serviced, the queuing system may decide to “promote” a lower precedence class client to be serviced as a high precedence class client. This may be done to keep the efficiency high in the queuing system. In other cases, when a high precedence class is over-booked with clients then the queuing system may decide to “demote” a higher precedence class client to be serviced as a low precedence class client. After the queuing system “remarks” (promotes or demotes) a client, there is an interest at least for fairness to service in order the remarked client and the other clients that originally belonged to the same precedence class. However, in the traditional queuing systems like the ones used in routers of a network shown in
Referring to
At the downstream router 106″, packet 1 waits in the lower precedence queue to be scheduled for transmission. Assume in this example that packet 1 finds packet 0 being transmitted so it has to wait. While packet 1 is waiting, packets 2 and 3 are received and queued in the higher precedence class. Upon completion of the transmission of packet 0, packets 2 and 3 are scheduled to go next since they are of higher precedence than packet 1. Notice that packets 1 and 3, which belong to the same flow, got reordered in the downstream router 106″. This reordering of packets 1 and 3 is not desirable.
The reordering of packets is strongly discouraged mainly due to the high complexity and high cost associated with handling per flow reordering (as described below). If reordering is not handled properly, some higher layer protocols, like TCP for example, suffer a severe performance impact since out-of-order packets indicate packet loss and therefore congestion. This problem is described in more detail in the following references the contents of which are incorporated herein:
In all of these queuing systems, the reordering of clients (packets) which originally belong to the same flow or service class when they entered the system is not desired and maybe even prohibited. In systems where several stages of service are required, the aforementioned restriction implies some cost on the routers (servers) servicing the clients (packets) if they need to maintain the order. The problem becomes even more complex when clients come in batches (i.e. flows) all labeled with the same QoS or precedence class and merge with other client batches (flows) into the same QoS queue. Accordingly, there is a need for a new queuing system and method for queuing clients (packets) in a manner that overcomes the reordering problem associated with the traditional queuing system. This need and other needs are satisfied by the queuing system and method of the present invention.
The present invention includes a QoS queuing system and a method for queuing clients (packets) in a manner that eliminates the reordering of the clients even after a QoS class of one of the clients is altered (promoted/demoted). In one embodiment, the method eliminates the reordering of a plurality of clients that includes an altered client by marking the altered client, which is located within a first node (first router), with an indicator that indicates an old QoS class and a new QoS class of the altered client. Upon receiving the altered client at a second node (second router), the indicator in the altered client is checked. And, then the altered client is queued in the old QoS class and the other clients are queued in the old QoS class. At this time, the proxy client is also allocated in the new QoS class. Once the proxy client is scheduled to be serviced by the second node, a head-of-line client selected from one of the clients queued in the old QoS class is serviced as being in the new QoS class instead of servicing and sending the proxy client to a third node (third router). Finally, the second node marks the head-of-line client with an indicator that indicates the old QoS class and the new QoS class of the head-of-line client before sending the head-of-line client to the third node.
A more complete understanding of the present invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
Referring to
As shown in
An example of the operation of the QoS queuing method 300 is described next with respect to two routers 206′ and 206″. Assume three packets are received at the router 206′ in the order 1, 2, 3. The first and the third packets belong to the same flow (e.g. TCP flow) and have a ‘lower precedence’ QoS class than the second packet which belongs to another flow. As such, packets 1 and 3 are in a lower precedence queue than packet 2. Assume packets 2 and 3 arrive at the time when packet 1 was being transmitted to router 206″. After packet 1 is transmitted, the scheduler 212 in router 206′ schedules packet 2 to go after packet 1 since packet 2 has a higher precedence class than packet 3. Assume also that packet 3, having complied with a certain policy, was promoted by the scheduler 212 in router 206′ to a higher precedence class. The altered packet 3, assuming originally it was in QoS class A and is now in QoS class B where QoS class B has higher precedence than QoS class A, is marked (step 302) with a special indicator 216a. The special indicator 216a is used to identify the old QoS class (e.g., QoS class A) of packet 3 as well as the new QoS class (e.g., QoS class B). The special indicator 216a also indicates that the class of service of packet 3 has been altered. Again, packet 3 had been promoted. In this example, the packets are transmitted in the order 1, 2, 3 to the downstream router 206″.
At the downstream router 206″, packet 1 waits in the lower precedence queue to be scheduled for transmission and assume packet 1 finds packet 0 being transmitted and has to wait. While packet 1 is waiting, packets 2 and 3 are received and packet 2 is queued in the higher precedence class. The downstream router 206″ then checks (step 304) the special indicator 216a in packet 3 and then queues (step 306) packet 3 in its original QoS class (e.g., QoS class A). The downstream router 206″ also fakes the presence of the “remarked” packet 3 in the new QoS class (e.g., QoS class B) by allocating (step 308) a proxy packet 218 in the new QoS class (e.g., QoS class B). This is done so that the scheduler 212 can allocate the servicing of another packet in the new QoS class (e.g., QoS class B) when the time comes to service the proxy packet 218. In particular, once the proxy client 218 is scheduled to be serviced, the head-of-line packet 1 in the old QoS class (e.g., QoS class A) is serviced (step 308) as a new QoS class-B packet instead of the proxy client 218. Prior to exiting the downstream router 206″, the altered packet 1 is marked (step 310) as a new QoS class-B packet 1 using the special indicator 216b. The special indicator 216b is used to identify the old QoS class (e.g., QoS class A) of packet 1 as well as the new QoS class (e.g., QoS class B). The special indicator 216b also indicates that the class of service of packet 1 has been altered. Again, packet 1 had been promoted. In this example, the packets 1 and 3 that originally belonged to the same flow or QoS class (e.g., QoS class B) did not get reordered but instead were transmitted in the order 1, 3 to another downstream router 206′″. This ordering of the packets 1 and 3 is desirable.
In the exemplary packet queuing system 200, the special indicator 216a and 216b can be a packet field value or a bit. For example, in Diffserv it can be a ‘special’ DSCP (Differentiated Services Code Point) value that indicates for instance that this packet was AF2: Assured Forwarding 2 (A Diffserv Quality of Service Class) and now is AF1: Assured Forwarding 1 (A Diffserv Quality of Service Class). And, the creation of the proxy packet 218 can depend on the implementation of the queuing and scheduling system in hardware. In one instance, it can be a pointer to the head-of-line packet of the second class. Then, when the scheduler 212 decides to schedule the proxy packet 218, the head-of-line packet of the second class is remarked and transmitted.
From the foregoing, it can be readily appreciated by those skilled in the art that the QoS method 300 of the present invention provides a solution to the reordering problem described above with respect to
To accomplish this, the router 206′ functions to mark (step 302) the altered packet with a special indicator 216a that indicates the old QoS class and the new QoS class of the altered packet. Then after the altered packet is received at the downstream router 206″, the special indicator 216a is checked (step 304). The downstream router 206″ then functions to queue (step 306) the altered packet in the old QoS class and also queue the other packets in the same flow within the old QoS class. Thereafter, the downstream node 206″ allocates (step 308) a proxy client 218 in the new QoS class. Once the proxy client 218 is scheduled to be serviced, the downstream router 206″ services (step 310) a head-of-line packet selected from the other packets queued in the old QoS class as being in the new QoS class instead of servicing and sending the proxy client 218 to another downstream router 206′″. Finally, the downstream router 206″ functions to mark (step 312) the head-of-line packet with a special indicator 216b that indicates the old QoS class and the new QoS class of the head-of-line packet before sending the marked packet to another downstream node 206′″.
Following are some additional features, advantages and uses of the QoS queuing method 300 of the present invention:
Although one embodiment of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it should be understood that the invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.
Patent | Priority | Assignee | Title |
8391255, | Aug 17 2006 | Cisco Technology, Inc. | Content throughput on wireless mesh networks |
Patent | Priority | Assignee | Title |
6023456, | Dec 23 1996 | RPX CLEARINGHOUSE LLC | Dynamic traffic conditioning |
6363053, | Feb 08 1999 | UNILOC 2017 LLC | Method and apparatus for measurement-based conformance testing of service level agreements in networks |
6515974, | Jun 16 1998 | Kabushiki Kaisha Toshiba | Mobile computer communication scheme supporting moving among networks of different address systems |
6633575, | Apr 07 1999 | Nokia Corporation | Method and apparatus for avoiding packet reordering in multiple-class, multiple-priority networks using a queue |
6822940, | Sep 29 2000 | Cisco Technology, Inc | Method and apparatus for adapting enforcement of network quality of service policies based on feedback about network conditions |
6839327, | Dec 01 2000 | Cisco Technology, Inc | Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions |
7006437, | Jul 06 2001 | SRI International | Scheduling mechanisms for use in mobile ad hoc wireless networks for achieving a differentiated services per-hop behavior |
7209482, | Dec 21 2001 | Juniper Networks, Inc. | Reorder engine with error recovery |
7281201, | Nov 26 2003 | SAP SE | Common message area for a customer interaction center user interface |
20040042456, | |||
20040044796, | |||
EP1372306, | |||
WO56013, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Sep 02 2004 | HADDAD, REDA | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015168 | /0381 | |
Sep 02 2004 | HADDAD, REDA | Ericsson Inc | CORRECTIVE ASSIGNMENT TO CORRECT ASSIGNEE S NAME, PREVIOUSLY RECORDED ON REEL FRAME 015168 0381 | 015488 | /0153 | |
Sep 08 2004 | Telefonaktiebolaget L M Ericsson (publ) | (assignment on the face of the patent) | / | |||
Jan 20 2005 | Ericsson Inc | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015610 | /0887 |
Date | Maintenance Fee Events |
Oct 01 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Sep 30 2016 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Nov 16 2020 | REM: Maintenance Fee Reminder Mailed. |
May 03 2021 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Mar 31 2012 | 4 years fee payment window open |
Oct 01 2012 | 6 months grace period start (w surcharge) |
Mar 31 2013 | patent expiry (for year 4) |
Mar 31 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
Mar 31 2016 | 8 years fee payment window open |
Oct 01 2016 | 6 months grace period start (w surcharge) |
Mar 31 2017 | patent expiry (for year 8) |
Mar 31 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
Mar 31 2020 | 12 years fee payment window open |
Oct 01 2020 | 6 months grace period start (w surcharge) |
Mar 31 2021 | patent expiry (for year 12) |
Mar 31 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |