|Publication number||US7102998 B1|
|Application number||US 09/273,948|
|Publication date||Sep 5, 2006|
|Filing date||Mar 22, 1999|
|Priority date||Mar 22, 1999|
|Publication number||09273948, 273948, US 7102998 B1, US 7102998B1, US-B1-7102998, US7102998 B1, US7102998B1|
|Inventors||S. Jamaloddin Golestani|
|Original Assignee||Lucent Technologies Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (11), Referenced by (23), Classifications (4), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The invention relates to data networks, and more particularly relates to an effective congestion control mechanism for multicast communications.
Some form of effective congestion control is needed in the operation of a data network to ensure that data packets will be forwarded to their respective destinations during periods of high demand for network resources. If the congestion control specified for a data network is not effective, then it is likely that data messages could be lost at a network location that is experiencing congestion.
There are several well-known forms of congestion control including rate based and window based controls. In a rate based control, a source transmits data packets at a predetermined rate. The source also monitors a number of well-known parameters and statistics indicative of network congestion including, for example, the round-trip-delay between the source and receiver, the number of packets which do not reach the receiver within a predetermined period of time as noted in acknowledgments that the receiver returns to the source, etc.
In a window based control scheme, the source stops its transmission of data packets to the receiver when it determines in a conventional manner that the number of outstanding, unacknowledged packets set for the transmission window has been reached. (The size of the window is typically based on, for example, the round trip delay between the source and receiver as well as the rate of packet losses.) The source resumes its transmission, keeping the number of outstanding data packets within the size of the window, when it receives an acknowledgment from the receiver. Similarly, the source may adjust the size of the window, and thus the number of outstanding packets that are transmitted during the window, based on different parameters and statistics indicative of network congestion that the source collects.
The foregoing controls work well for unicast transmissions involving a source and a single receiver. Also, the burden of continually accumulating such network parameters and statistics to regulate the transmission rate or the size of window is minimal in a unicast transmission. However, that is not the case for multicast transmissions where a data packet is routed to a large number of receivers based on a particular parameter, e.g., a group address. The reason for this is that a source in a multicast system would have to continually accumulate statistics for each receiver and calculate a rate or window suitable for all of the receivers, which would severely burden the processing and computational time at the source. Thus, performing congestion control in a multicast system involving a very large number of receivers, e.g., >100 receivers, would be a formidable undertaking.
I have recognized that the computational burden involved in implementing congestion control with regulation for multicast transmission should be shifted to the receivers, with each receiver computing a congestion control value/parameter using its respective statistics, and then forwarding the congestion control value to the source. The source then selects a predetermined one of the congestion control values that it receives from the receivers and uses the selected value to control the transmission of data messages, all in accordance with the invention.
As an aspect of the invention, the selected congestion control value may be based on the minimum of the received values.
As another aspect of the invention, a hierarchical reporting network is used to convey the congestion control values from the receivers. Specifically, congestion control values generated by the receivers are consolidated at various layers in the hierarchical reporting network so that the source receives consolidated congestion control values from just the receivers connected directly to the source, rather than a value from each of the receivers.
These are and other aspects of invention are set forth in following detailed description and accompanying drawings.
In the drawing:
A broad block diagram of a portion of a data network in which the principles of the invention may be practiced is shown in
(Note that the following description first discusses the various aspects of the invention in the context of a window based scheme. It then discusses a rate based scheme.)
As mentioned above, each of the receivers in a window based scheme, in accordance with the invention, continuously monitors its transmission path from the source to itself in any appropriate manner to collect various statistics (e.g., the number of lost data packets indicative of the level of congestion occurring along that path). The receiver uses the collected statistics to regularly update its respective transmission window size for the purpose of congestion control. It then determines a congestion control value as a function of the window size and other local parameters discussed below.
(For the purpose of the following discussion, it is noted that a sequence number is typically associated with a respective data packet in a system which uses a data packet of a fixed sized; whereas, a sequence number is typically associated with the last data byte in the payload of a packet in a system which uses a data packet of a variable size.)
Specifically, assume, for example, that at time t receiver 300-i has a window size of wi and that the sequence number of the last data packet that receiver 300-i received successfully from source 100 is mi and all packets up to mi have been received. Receiver 300-i then returns as feedback to source 100 a congestion control value, ni, determined as follows:
n i =w i +m i (1)
where ni identifies the maximum sequence number that source 100 may transmit with respect to receiver 300-i. For example, If wi equals 8 and mi equals the sequence number of 152, then receiver 300-i returns as feedback a transmission congestion control value of 160 to indicate that the source may transmit, for example, those data packets respectively having sequence numbers through 160. Similarly, source 100 receives a congestion control value from each of the receivers in the multicast group. To meet the congestion control requirement for the multicast group, source 100 selects, for example, the smallest of the congestion control values that it respectively received from the receivers, and uses the selected value as the maximum sequence number for the data packets that the source may transmit to the multicast group.
Advantageously, then, the bulk of the congestion control activity is performed at the receivers, rather than at the source or transmitter.
The computation of a congestion control value by a receiver 300-i when packets are not received in sequence may be determined as follows. Specifically, assume that at time t the transmission window is wi, that receiver 300-i successfully received all of the data packets up to sequence number mi, and that ki denotes the total length of the data packets that have been received after sequence number mi (or are not expected to be received at a later time). For that case, then, ni may be expressed in the following way:
n i =m i +k i +w i (2)
A receiver may thus account for outstanding data packets in the congestion control value that it returns to the transmitter. Note that each of the receivers performs the foregoing using its respective statistics and returns the resulting congestion control value as feedback to the source.
It is well-known that a receiver of data packet uses a buffer to assemble in proper order data messages that it receives from a source. It is also well-known that the buffer may overflow when data messages are received faster than they can be re-assembled in sequence for delivery to an upper-layer processor. The task of preventing a re-assembly buffer from overflowing at a receiver is thus an important aspect of window congestion control in a data network, e.g., the Internet. In Internet, or TCP, terminology, this protection function is called “flow control”. I have recognized that the inventive receiver window-based control scheme described immediately above could be adapted to include flow control. In particular, assume that Bi notes the amount of space that is available in the re-assembly buffer for storing data messages that have been received out of sequence at receiver 300-i following receipt of the data message of sequence number mi. Also Assume that the out-of-sequence data messages need to be re-assembled in proper sequence before they can be delivered to an application layer. For that case, then, a received data messages having a sequence number greater than mi+Bi could be lost as a result of congestion occurring at the re-assembly buffer. This problem may be dealt with by including that statistic in the determination of the congestion control value, ni, in the following way:
n i =m i+min(k i +w i, Bi) (3)
It can be appreciated from the foregoing that the source will regularly receive a feedback message from each of the receivers in the multicast group. If the group is formed by a large number of receivers, e.g., >100, then the source will receive a like number of feedback messages. The processing of a large number of feedback messages at the source could consume an appreciable portion of the processing time at the source. I deal with this problem, in accordance with an aspect of the invention, by organizing the receivers into a hierarchical reporting structure (tree structure) for the purpose of performing feedback consolidation at receivers positioned at intermediate and higher layers in the hierarchical reporting network and presenting source 100 instead with what I call consolidated-congestion-control-feedback messages. Accordingly, then, source 100 need only process a few consolidated feedback messages which summarize the content of the feedback messages transmitted by the receivers forming multicast group 300.
Each receiver, more particularly, consolidates congestion control values that it receives from receivers that are positioned at a lower layer in the hierarchy and directly connected to it (i.e., each of its children) and forwards the consolidated result upward to the receiver positioned at a next higher layer in the hierarchy (i.e., its parent). A receiver, e.g., receiver 300-j,
F j=min[f j, minkεC
where fj is equal to the local congestion control value, i.e., nj, that receiver 300-j calculated; Fk is the most recent consolidated congestion control value received as feedback from the child receivers, such as receivers 300-k and 300-l, positioned at the preceding level; and Cj denotes the set of children receivers, such as receivers 300-k and 300-l, that report to receiver 300-j; i.e., those receivers positioned below (i.e., connected to) receiver 300-j in the reporting hierarchy. (Note that if receiver 300-j has no children, then Cj is an empty set and Fj=fj.) Source 100, in turn, processes the contents of the consolidated feedback messages that it receives from those receivers that report directly to source 100 to determine the minimum of all of the sequence numbers generated by the receivers 300. Source 100 then transmits the data packets up to the sequence number specified by the determined minimum.
The various aspects of the invention described above may also be applied to a multicast network employing a rate based congestion control scheme. Specifically, each receiver, 300-i, in the multicast group continually monitors its specific transmission path from the source to the receiver in any appropriate manner to collect various statistics/data (e.g., the number of lost data packets) indicative of the level of congestion occurring along that path, as mentioned above. The receiver regularly updates the maximum acceptable rate, ri, at which it should be receiving data packets from source 100 via its specific transmission path as a function of the latest of such statistics. The receiver 300-i then forwards the determined rate as feedback, fi, to the next highest level in the hierarchical reporting network. In the manner described immediately above, a receiver thereat consolidates the various feedback values that it recently received from the receivers in the preceding layer, Fi, with its own feedback value, fj, using expression (4) and forwards the consolidated transmission rate, Fj, to the next highest layer, which could be source 100. Source 100, in turn, selects as the transmission rate at which it will transmit the next set of data messages the minimum of the feedback values, Fj, that it received from the receivers that report directly to source 100 via the hierarchical network.
It is noted that the architecture of the reporting hierarchy formed by the receivers shown in
In general, the feedback messages, Fj, that a receiver sends upstream may be sent each time Fj changes. Note that the number of feedback messages, Fj, that are transmitted upstream may be reduced by arranging each receiver so that it transmits a consolidated feedback message periodically, e.g., a period equal to the round trip delay between itself and source 100, or a more definite period of time, e.g., once every two milliseconds.
Also note that, depending on the algorithm used to update wj or rj, a receiver may need to know the round trip delay between itself and source 100. The following presents an algorithm that estimates the receiver round trip time, in which the algorithm assumes that some kind of clock synchronization exists between the source and receivers.
Specifically, consider that τsj is the one way delay from source 100 to receiver 300-j; τ js is the one way delay from receiver 300-j to the source 100; and that receiver 300-j maintains the delay parameter τks for each of its child receivers 300-k. Receiver 300-j also supplies the delay value τks to its child receiver 300-k and continuously updates that value as described below. In addition, source 100 inserts a time stamp in each of the data packets that its transmits to the multicast group. When receiver 300-j receives a multicast transmission it determines the difference between the value of the time stamp contained in the received packet with the time at which it received the packet, and uses that difference as a new sample, S, to update τsj in the following manner:
where τsj is an exponentiated weighted running average of the sample S. If the feedback from receiver j is sent periodically with a period of δj, then the waiting time from the arrival of a packet until the transmission of the next feedback is a random variable between 0 and δj that has uniform distribution and an average value equal to 1/2δj. Moreover, the parent of receiver 300-j, e.g., source 100, maintains a running average of the delay that occurs in receiving a feedback message with a respective time stamp from each of its children and supplies the calculated delay, e.g., τjs, to the respective child receiver 300-j. Receiver 300-j, upon receipt of τjs from its parent receiver uses that value to calculate and store in its local memory a running average of the trip delay from each of its child receivers to the source as shown in the following manner for receiver 300-k:
Receiver 300-j also performs a similar calculation for each of its other child receivers, such as receiver 300-l. It then sends δks to each child receiver 300-k.
Also, each receiver 300-j calculates its round trip time τj from the source as follows:
An exemplary embodiment of source 100 is shown in
An exemplary embodiment of a receiver 300 is shown in
It will thus be appreciated that, although the invention illustrated herein is described in the context of a specific illustrative embodiment, those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly shown or described herein, nevertheless, embody the principles of the invention and are within its spirit and scope.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5313454 *||Apr 1, 1992||May 17, 1994||Stratacom, Inc.||Congestion control for cell networks|
|US5633859 *||Sep 16, 1994||May 27, 1997||The Ohio State University||Method and apparatus for congestion management in computer networks using explicit rate indication|
|US5727002 *||Jan 16, 1996||Mar 10, 1998||Starburst Communications Corporation||Methods for transmitting data|
|US5831973 *||Oct 11, 1996||Nov 3, 1998||Mitsubishi Denki Kabushiki Kaisha||Multicast connection control method and apparatus|
|US6112323 *||Jun 29, 1998||Aug 29, 2000||Microsoft Corporation||Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems|
|US6115749 *||Oct 14, 1997||Sep 5, 2000||Lucent Technologies Inc.||System and method for using a window mechanism to control multicast data congestion|
|US6151633 *||Apr 20, 1998||Nov 21, 2000||Sun Microsystems, Inc.||Method and apparatus for routing and congestion control in multicast networks|
|US6151696 *||Jan 23, 1998||Nov 21, 2000||Starburst Communications Corporation||Data transmission|
|US6205120 *||Mar 13, 1998||Mar 20, 2001||Packeteer, Inc.||Method for transparently determining and setting an optimal minimum required TCP window size|
|US6427166 *||Sep 22, 2000||Jul 30, 2002||Sun Microsystems, Incorporated||Method and apparatus for routing and congestion control in multicast networks|
|US6487603 *||Oct 19, 2000||Nov 26, 2002||3Com Corporation||Method and apparatus for real time communication over switched networks|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7526523 *||Jun 12, 2003||Apr 28, 2009||British Telecommunications Public Limited Company||Timer-based feedback in multicast communication|
|US7561523 *||Jul 14, 2009||Netapp, Inc.||Method and apparatus for flow control in a reliable multicast communication system|
|US7729245 *||Jan 4, 2007||Jun 1, 2010||At&T Intellectual Property Ii, L.P.||Method and system of monitoring the receipt of multicast traffic|
|US7769629 *||Sep 23, 2002||Aug 3, 2010||Marketing Technology Concepts, Inc.||System and method for providing hierarchical reporting for online incentive programs|
|US7814218||Oct 12, 2010||Astute Networks, Inc.||Multi-protocol and multi-format stateful processing|
|US8015303||Aug 2, 2002||Sep 6, 2011||Astute Networks Inc.||High data rate stateful protocol processing|
|US8151278||Sep 11, 2008||Apr 3, 2012||Astute Networks, Inc.||System and method for timer management in a stateful protocol processing system|
|US8306043||May 21, 2010||Nov 6, 2012||At&T Intellectual Property Ii, L.P.||Method and system of monitoring the receipt of multicast traffic|
|US8477608||Oct 26, 2006||Jul 2, 2013||Unwired Planet, Llc||Method and receiver for controlling the conformance of a data flow in a communication system to a traffic definition|
|US8773982 *||May 18, 2011||Jul 8, 2014||Panasonic Corporation||Transmitting terminal and bandwidth estimating method|
|US8929221||Oct 4, 2012||Jan 6, 2015||At&T Intellectual Property Ii, L.P.||Method and system of monitoring the receipt of multicast traffic|
|US9013998||Aug 20, 2012||Apr 21, 2015||Amazon Technologies, Inc.||Estimating round-trip times to improve network performance|
|US20020078184 *||Dec 10, 2001||Jun 20, 2002||Eiji Ujyo||Record medium, multicast delivery method and multicast receiving method|
|US20040024894 *||Aug 2, 2002||Feb 5, 2004||Osman Fazil Ismet||High data rate stateful protocol processing|
|US20050207354 *||Jun 12, 2003||Sep 22, 2005||Maziar Nekovee||Timer-based feedback in multicast communication|
|US20060114837 *||Jan 19, 2006||Jun 1, 2006||Wlodek Olesinski||Method and apparatus for processing requests for statistics in a communication network|
|US20100046374 *||Oct 26, 2006||Feb 25, 2010||Reiner Ludwig||Method and receiver for controlling the conformance of a data flow in a communication system to a traffic definition|
|US20100180042 *||Jul 15, 2010||Microsoft Corporation||Simulcast Flow-Controlled Data Streams|
|US20100226277 *||Sep 9, 2010||At&T Corp.||Method and system of monitoring the receipt of multicast traffic|
|US20120128002 *||May 18, 2011||May 24, 2012||Panasonic Corporation||Transmitting terminal and bandwidth estimating method|
|CN102484616A *||May 18, 2011||May 30, 2012||松下电器产业株式会社||Transmitting terminal and band estimation method|
|CN102484616B *||May 18, 2011||Feb 25, 2015||松下电器产业株式会社||Transmitting terminal and band estimation method|
|WO2008049462A1 *||Oct 26, 2006||May 2, 2008||Telefonaktiebolaget Lm Ericsson (Publ)||A method and receiver for controlling the conformance of a data flow in a communication system to a traffic definition|
|Jun 14, 1999||AS||Assignment|
Owner name: LUCENT TECHNOLOGIES INC., NEW JERSEY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GOLESTANI, S. JAMALODDIN;REEL/FRAME:010030/0049
Effective date: 19990517
|Mar 1, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Feb 28, 2014||FPAY||Fee payment|
Year of fee payment: 8