Patent Grant
8077606
1. Field of the Invention
The present invention relates generally to resource management and admission control of multimedia data flows and more specifically to management of multimedia data flows that are congested.
2. Description of Background Art
Multimedia data broadcast over an IP (Internet Protocol) infrastructure is a well-known way of transmitting and receiving multimedia data in today's information age. Unlike other forms of data (like text data), multimedia data is dependent upon an uninterrupted, constant flow of data packets (constant bit rate or CBR), to maintain the quality of the data received by an end user. The data packets in a multimedia data flow for standard cable TV viewing proceed through the IP network at a constant bit rate, such as 3.75 M bits per second which corresponds to 356 IP packets/second. Multimedia data flow for CATV or HDTV systems is transmitted through the IP network to an end user's set top box (STB). The set top box is designed to receive the multimedia data flow and format the data properly for display on the user's television.
Difficulties arise during management of multimedia data over an IP network during times of congestion. CBR multimedia data over IP networks cannot use conventional congestion control techniques such as RED, WRED, etc. Applying these methods causes severe degradation to all multimedia data flows traversing the link. In conventional systems during periods of congestion, all degraded multimedia data flows are allowed to pass through the IP network and are received by the set-top box. Because the STB is receiving some information, albeit corrupted information, the STB is unable to detect and report a problem to the data sender. Conventional congestion control methods do not always preserve the integrity of any of the multimedia data flows during a period of network link congestion.
When congestion occurs in a conventional network, a need arises to notify the source. Several congestion notification techniques exist for notifying a source of a congestion condition within a network. In Internet Control Message Protocol (ICMP), a gateway within the IP network may send a source quench message to an internet source of a multimedia data flow if the multimedia data is being sent too fast for the gateway to handle. A destination host may also send a source quench message if multimedia data flows arrive too fast to be processed. The source quench message is a request to the source to decrease the rate at which it is sending multimedia data flows to the internet destination. On receipt of a source quench message, the source host decreases the rate at which it is sending traffic to a predetermined rate or pauses the traffic to the specified destination for a predetermined period of time.
Another method for congestion notification is forward-explicit congestion notification (FECN) and backward-explicit congestion notification (BECN) within a Frame Relay network. FECN involves a header bit transmitted by the source (sending) terminal requesting that the destination (receiving) terminal slow down its requests for data. BECN (backward explicit congestion notification) involves a header bit transmitted by the destination terminal requesting that the source terminal send data more slowly. FECN and BECN are controlled by a single bit contained in the Frame Relay frame header. The Frame Relay frame header also contains a Discard Eligibility (DE) bit, which is used to identify less important traffic that can be dropped during periods of congestion.
Significant drawbacks are present within the ICMP and Frame Relay congestion notification techniques. The source quench message of ICMP and Frame Relay are sent only to the source. Moreover, the techniques do not take into consideration the fact that in today's media-rich environment, a single entity on a network may be a source or destination for multiple streams of data.
What is needed is an efficient way of improving network congestion notification.
A preferred embodiment of the present invention is now described with reference to the FIGs where like reference numbers indicate identical or functionally similar elements. Also in the FIGs, the leftmost digit(s) of each reference number correspond(s) to the FIG in which the reference number is first used.
An embodiment of the present invention introduces a congestion control mechanism for constant bit rate (CBR) multimedia data flows in IP networks. A flow drop method within a congestion control unit of the present invention chooses a subset of multimedia data flows to drop, in whole, to alleviate a congestion condition. Substantial benefits are provided by the claimed invention. After the congestion condition is detected and the congestion control unit begins dropping multimedia data flows, the remaining multimedia data flows are no longer degraded for the end user, as compared to conventional congestion management systems. Also, the complete drop of only a portion of the multimedia data flows allows those user devices associated with the dropped flows to detect the problem and take corrective or alternate action.
According to an embodiment, the present invention is invoked by a congestion condition being reached, or by a configurable bandwidth threshold. After detecting the congestion condition, the flow drop method randomly selects one or more of the multimedia data flows to be dropped. This randomly selected flow is completely dropped from the data transmission. If congestion continues, another flow, as determined by the congestion control unit, is dropped, and so on, until congestion subsides or the configurable bandwidth threshold is reached.
Within the IP network 112 is a first router 114, a second router 118, and a third router 116. IP network 112 is communicatively coupled, via a wired or wireless connection 140, to an end user's set-top-box (STB) 120. First router 114, second router 118, and third router 116 determine the next network point to which a data packet within a particular multimedia data flow should be forwarded, enroute to its destination. First router 114, second router 118, and third router 116 also create or maintain a table of the available routes for a given multimedia data flow and use this information to determine a route for packets in the given multimedia data flow to proceed through the IP network 112. A skilled artisan will envision a multimedia data over IP network with any number of routers within the network arranged to determine routes for transmitting multimedia data flow from a variety of multimedia sources to one or more destinations (i.e., one or more STBs).
The individual multimedia data flows, as shown in
As shown in
In an embodiment, within a network router, a separate logical egress queue (or multiple queues) can be established to store multimedia data flows of a particular priority level to be sent out egress interface 210. The congestion control unit 200, operating on the logical egress queue 207, and the flow drop method 208 make decisions as to which queue is filled if there are multiple queues present within egress queue 207. These decisions are based on values in the multimedia data flow header, such as IP addresses, UDP port numbers, and DSCP/TOS values, using well-known routing techniques. The flow drop method 208 can be implemented in either hardware or software.
When a congestion condition has been reached, the flow drop method 208 is adapted to drop lower priority multimedia data flows. A more detailed discussion of dropping multimedia data flows occurs later on. Once an appropriate number of multimedia data flows have been dropped, the congestion condition is relieved and the flow of multimedia data flows from the logical egress queue 207 to the egress interface 210 returns to an un-congested state. Here, flow drop method 208 drops all of the low priority flows (8, 9, 10) and one randomly chosen medium priority flow (6). Dropped packets are logged or archived in memory 220. The flow dropping method of the present invention is adapted to drop all packets and streams associated with a particular flow that is marked as dropped. In certain embodiments, because an entire flow is being dropped, the source receives some form of notification that the flow has been dropped, thus discontinuing the transmission of that particular flow. The receiver of a dropped flow may also receive a notification that the flow has been dropped by the network. Certain accounting information, including UDP, IP, RTP source and destination addresses, can be used to identify a packet as a member of a particular flow when determining which flows to drop. The accounting information can also aid in the determination of the priority level of a particular multimedia data flow.
Within the congestion control unit 200, the flow drop method 208 monitors 302 the multimedia data flows and determines 304 whether a congestion condition occurs. If no congestion occurs, the flow drop method 208 instructs the congestion control unit 200 to continue monitoring the flow of multimedia data flows until a congestion condition does occur. Once a congestion condition occurs, the flow drop method 208 determines 306 which flow or sets of flows are to be dropped in order to relieve 316 the congestion condition.
The determination of which flows are dropped by flow drop method 208 continues in
The flow drop method 208 is adapted to continue dropping flows until the congestion condition is relieved. Once the congestion condition is relieved 316, the flow drop method 208 determines 318 whether any entries remain in the flow drop table. If the flow drop method 208 determines there are entries in the flow drop table, the flow drop method 208 is adapted to carry out the steps outlined in
The determination of which flows are removed by flow drop method 208 from the flow drop table continues in
The congestion control unit 200 is adapted to monitor multimedia data flows in a strict priority dequeuing embodiment. In this embodiment, when the flow drop method 208 detects a full egress queue in step 304 of
Initially, the flow drop method 208 determines 404 if the high priority queue is full. If the high priority queue is full, the flow drop method 208 randomly selects 406 a high-priority flow to drop and marks 408 the selected high-priority flow as dropped in the flow drop table. The flow drop method 208 then marks 410 all multimedia data flows in the lower priority queues as dropped in the flow drop table. The dropped multimedia data flows (or information about them) are then logged or archived in memory unit 220 and the method 208 returns the congestion control unit 200 to step 316. In another embodiment, the flow drop method 208 is capable of estimating how many high-priority multimedia data flows, in a set of high-priority flows, to drop in order to alleviate the congestion condition. In this embodiment, the method then drops the estimated set of high-priority multimedia data flows, along with all multimedia data flows from the lower priority queues, to alleviate the congestion condition.
If the flow drop method 208 determines 404 that the high-priority queue is not full, the method moves to
If the flow drop method 208 determines 412 that the medium-priority queue is not full at the egress interface 210, the method moves to
In this embodiment, flow drop table 506 contains at least two fields:; a flow identification field and a flow drop field. Flow drop table 506 is capable of supporting one or more multimedia data flows, as determined by the network administrator. The flow identification field contains certain accounting information that allows the congestion control unit 200 the ability to uniquely identify the source, destination, and priority of a particular multimedia data flow. This information uniquely identifies multimedia data packets belonging to the multimedia flow. The flow identification field can be defined by source IP, source UDP, source RTP, destination IP, destination UDP, and destination RTP. In another embodiment, the flow identification field can be defined by the destination IP and the destination UDP. The flow identification field can also contain a numerical designation representing a particular multimedia data flow passing through the IP network. The flow drop field contains a symbolic designation representing that a particular flow has been marked to be dropped. One skilled in the art will appreciate other embodiments of flow drop table 506 that contain only the flow identification field and the flow drop field.
As shown in
Once a notification message is created 606 for the source of each dropped flow (also called a “dropped source”), the flow drop method 208 sends 608 a notification message to each of the sources of the dropped multimedia data flows. When the notification message is received 610 by the dropped source, the source of the dropped multimedia data flows discontinues 614 transmission of the dropped multimedia data flows.
As also shown in
Once a notification message is created 614 for the destination of each dropped flow (also called a “dropped destination”), the flow drop method 208 sends 616 a notification message to each of the destinations of the dropped multimedia data flows. When the notification message is received 618 by the dropped destination, each destination of the dropped multimedia flows performs 619 at least one predetermined action, such as displaying a notice that the multimedia data flow has been temporarily dropped. Another example of an action taken by a destination receiving notice that a multimedia flow has been dropped is that the destination re-requests the stream to be sent after a timeout. In this situation, for example, the source might use the information and/or report it to an upstream management system to help correlate the failure. In some embodiments, the different destinations perform different predetermined actions. In some embodiments, any single destination may perform different predetermined actions for different dropped flows.
It will be noted that in the described embodiment, notification messages are sent to both the source and destination of a dropped multimedia data flow. Because multiple dropped data flows are included in these packets, the notification messages are sent to the source and destination
In
This “value” portion” can contain any information that identifies the multimedia data flow. For example, the value portion might contain information extracted from multimedia data flow packets such as a unique IP source and IP detination address for the dropped flow. As another example, the value portion might contain a UDP source port and a UDP destination port of the dropped flow. Elements 630 and 632 are repeated 634 for each flow dropped from this source. Lastly, a type of “end” is added to indicate the end of the notification message and the notification message is ready to be sent, so the flow drop method 208 returns to step 608 of
In
In an embodiment, the source of the notification message is an in-line router located within the network. In some embodiments, a notification message is sent from a node or entity dedicated to that function instead of by the node or entity that made a decision to drop the multimedia data flow. Thus, in some embodiments, the function of sending notification packets can be offloaded to a separate functional unit.
The header 702 of the notification message 700 identifies, among other things, a destination of the notification message, such as an IP address of the flow source or flow destination that will receive the notification message. Other embodiments may contain, for example, a UDP port number for the destination of the notification message.
Each of the fields 704/704′ of the notification message contain information identifying a dropped multimedia data flow. The information also includes a type of “notification” and a length of the value information. The value information identifies a dropped multimedia data flow. Here, a message sent to a source might identify a first subgroup of the multimedia flows to be dropped (i.e., the dropped flows originating at that source). A message sent to a destination might identify a second subgroup of the multimedia flows to be dropped (i.e., the dropped flows destined for that destination). In another embodiment, the value information contains at least an IP address for the source of the dropped multimedia data flow and an IP address for a destination of the dropped multimedia data flow since these two pieces of information are sufficient to identify a multimedia data flow. In another embodiment, the value information contains at least an IP address for the source of the dropped multimedia data flow, an IP address for the destination of the dropped multimedia data flow, a UDP port number for the source of the dropped multimedia data flow, and a UDP port number for the destination of the dropped multimedia data flow. In another embodiment, the value information contains at least an IP address for the source of the dropped multimedia data flow, a IP address for the destination of the dropped multimedia data flow, a UDP port number for the source of the dropped multimedia data flow, a UDP port number for the destination of the dropped multimedia data flow, an RTP address header for the source of the dropped multimedia data flow, and an RTP address header for the destination of the dropped multimedia data flow. In an embodiment, the specific value information stored within field 704/704′ is a user-configurable value. One of ordinary skill in the art will appreciate that the value information contains at least enough information to sufficiently identify the dropped multimedia data flow.
In an embodiment, the field 704 is packaged in a value field of a type-length-value (TLV) encoded payload. In this embodiment, the length field of the type-length-value encoded payload determines the size (in bytes or any particular unit) of the second set of accounting information packaged within the value field of the TLV encoded payload. In an embodiment, the length of the TLV encoded payload representing the size of the second set of accounting information is 64 bytes. In an embodiment, the length and value fields in the TLV encoded payload are user-configurable values that can be set to a length and value sufficient to uniquely identify the multimedia data flow that has been dropped. The type field of the type-length-value encoded payload identifies what type of multimedia data is identified by the second set of accounting information. In an embodiment, the number of fields 704′ in stored in a notification message 700 depends upon a network maximum transmission limit. In the case that the notification message 700 exceeds the network maximum transmission limit, the flow drop method 208 is adapted to create additional notification messages 700 that alert the source and destination of the dropped multimedia data flows regarding the status of all of the dropped multimedia data flows. In an embodiment, a network maximum transmission unit is 1500 bytes, as is the case with Ethernet.
Once the notification message 700 is created, the flow drop message is adapted to send the message 700. The notification message 700 can be sent based upon a variety of conditions. In an embodiment, the message 700 is sent when the message exceeds the network maximum transmission limit. In an embodiment, the message 700 is sent when the processing of the drop table 506 is complete and the flow drop method 208 determines that no multimedia data flows remain to be dropped. In an embodiment, the notification message 700 is sent when an administrative configurable timeout occurs, which can be 100 milliseconds, or any particular time suitable to the particular network constraints envisioned by the network administrator.
As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, managers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. For example, modules can be implemented as portions of computer readable instructions contained in a memory of a data processing system and executed by a processor of the data processing system. In one embodiment, computer-executable instructions may be contained on a computer readable medium that is included in a computer program product. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, managers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming.
In another embodiment, a separate network entity provides congestion relieving services to one or more network entities, such as routers or other network nodes, by performing the sending of notification messages (as described above) at the behest of the entity, once when the entity has determined which data flows to drop.
While the present invention has been described with reference to certain preferred embodiments, those skilled in the art will recognize that various modifications may be provided. For example, certain embodiments employ multiple application servers, acting in cooperation to perform a function or request. Any of the above functions or requests can be sent across a network, or using local cables such as IEEE1394, Universal Serial Bus, or wireless networks such as IEEE 802.11 or IEEE 802.15 networks, in any combination. Variations upon and modifications to the preferred embodiments are provided for by the present invention, which is limited only by the following claims.
This application is a continuation-in-part of U.S. patent application Ser. No. 11/225,302, entitled “Multimedia Data Flow Dropping” of Mark Litwack, that was filed on Sep. 12, 2005, which is herein incorporated by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5828653 | Goss | Oct 1998 | A |
| 6052376 | Wills | Apr 2000 | A |
| 6134239 | Heinanen et al. | Oct 2000 | A |
| 6157613 | Watanabe et al. | Dec 2000 | A |
| 6188671 | Chase et al. | Feb 2001 | B1 |
| 6336143 | Diedrich et al. | Jan 2002 | B1 |
| 6363069 | Levy et al. | Mar 2002 | B1 |
| 6377547 | Levy et al. | Apr 2002 | B1 |
| 6424620 | Nishihara | Jul 2002 | B1 |
| 6851008 | Hao | Feb 2005 | B2 |
| 6870812 | Kloth et al. | Mar 2005 | B1 |
| 6922396 | Knappe | Jul 2005 | B1 |
| 6934256 | Jacobson et al. | Aug 2005 | B1 |
| 6981054 | Krishna | Dec 2005 | B1 |
| 7035212 | Mittal et al. | Apr 2006 | B1 |
| 7061861 | Mekkittikul et al. | Jun 2006 | B1 |
| 7106691 | DeCaluwe et al. | Sep 2006 | B1 |
| 7299277 | Moran et al. | Nov 2007 | B1 |
| 7376085 | Yazaki et al. | May 2008 | B2 |
| 7417995 | Rabie et al. | Aug 2008 | B2 |
| 7450509 | Hao | Nov 2008 | B2 |
| 7480239 | Sundaresan et al. | Jan 2009 | B1 |
| 7809007 | Mayhew et al. | Oct 2010 | B2 |
| 20010048662 | Suzuki et al. | Dec 2001 | A1 |
| 20020003777 | Miyamoto | Jan 2002 | A1 |
| 20020054568 | Hoogenboom et al. | May 2002 | A1 |
| 20020097678 | Bisher, Jr. et al. | Jul 2002 | A1 |
| 20020122387 | Ni | Sep 2002 | A1 |
| 20030002438 | Yazaki et al. | Jan 2003 | A1 |
| 20030123447 | Smith | Jul 2003 | A1 |
| 20040008697 | Millard et al. | Jan 2004 | A1 |
| 20040081080 | Ji et al. | Apr 2004 | A1 |
| 20040085984 | Elzur | May 2004 | A1 |
| 20040192333 | Khokhar | Sep 2004 | A1 |
| 20050192812 | Buchholz et al. | Sep 2005 | A1 |
| 20050276230 | Akahane et al. | Dec 2005 | A1 |
| 20060007859 | Kadambi et al. | Jan 2006 | A1 |
| 20060114820 | Hunt et al. | Jun 2006 | A1 |
| 20060159016 | Sagfors et al. | Jul 2006 | A1 |
| 20060184990 | Kwak et al. | Aug 2006 | A1 |
| 20060198308 | Vasseur et al. | Sep 2006 | A1 |
| 20060251000 | Williams | Nov 2006 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11225302 | Sep 2005 | US |
| Child | 11292757 | US |
