Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
2000-10-03
2004-11-16
Lin, Wen-Tai (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C709S232000, C709S223000, C709S225000, C370S229000, C370S230000, C370S233000
Reexamination Certificate
active
06820128
ABSTRACT:
FIELD OF THE INVENTION
The invention generally relates to computer networks and, more particularly, the invention relates to processing various types of data in a network node for transmission in a manner specified for the various types of data.
BACKGROUND OF THE INVENTION
Data packets are utilized as a common transport medium for transmitting different types of data across the Internet. For example, data packets are used to transmit both audible data (e.g., Voice over IP) and data files (e.g., World Wide Web pages and word processing documents) over the Internet. Accordingly, a number of specialized data transmission protocols have been developed to transmit both types of data packets across the Internet. Among others, a widely used protocol for transmitting audible data is known in the art as the User Datagram Protocol (“UDP”), while a widely used protocol for transmitting files is known in the art as the Transport Control Protocol (“TCP”).
There are instances when data packets with audible data should be transmitted with a minimal delay between a transmitter and a receiver. One such instance is when audible data in received packets are to be converted into an output audible signal upon receipt by the receiver (i.e., real time audio data). In such case, the data packets should be transmitted with a minimal delay to ensure that the output audible signal is intelligible to the human ear. As known in the art, an end-to-end delay of about 100 milliseconds or greater generally produces some noticeable degradation in the output audible signal. Such degradation can be merely annoying to a listener, or reduce signal quality to the point where it is unintelligible to a listener. Conversely, audible data can tolerate limited data packet loss since the human ear can compensate for some missing data within an audible signal. Various protocols for transmitting audible data (e.g., UDP) therefore permit a controlled packet loss during transmission in an effort to minimize end-to-end delay between the transmitter and the receiver.
In contrast to data packets with audible data, files transmitted in data packets generally can tolerate some transmission delay between the transmitter and the receiver. Such data types at the application layer level, however, generally cannot tolerate any loss of data packets since data loss can corrupt the entire data file being transmitted. For example, if the object code of an application program is being downloaded by a receiver, loss of just a small number of data packets can cause the entire application program to malfunction, when subsequently executing on the receiver (i.e., the program can crash on the receiver). Conversely, if such application program was downloaded in fifteen minutes on a conventional 56 kilobytes per second modem, then a slight delay of an additional few seconds should not be noticeable to the user. Network designers therefore have developed various data transport protocols, such as TCP, that intentionally permit some additional packet retransmission delay in an effort to eliminate the packet drop rate.
It should be noted that applications (i.e., the application layer) generally are not tolerant to data loss. Applications nevertheless are tolerant to a small data loss at the network layer since retransmission is received at the transmission layer (i.e., at TCP).
A single network device transmitting both of the above noted types of data packets undesirably commonly improves performance of one type of data at the expense of the other type of data. For example, a network device can ensure that all received packets with audible data are transmitted immediately upon receipt. During burst transmissions of both types of data, data packets with files consequently can be dropped to ensure that the data packets with audible data are transmitted. Dropping data packets with files, however, causes the problems noted above. To obtain entire data files, such data must be re-transmitted, further causing congestion problems in the network.
Moreover, single network devices transmitting both types of data (e.g., via TCP and UDP, respectively) can also have the additional problem of requiring relatively large delay for congestion control. Specifically, TCP requires that a relatively large average queue size be maintained. Undesirably, however, such a large queue can produce an unnecessary delay on packets with audible data.
SUMMARY OF THE INVENTION
In accordance with one aspect of the invention, an apparatus and method of managing received packets to be transmitted from a network device stores the received packets on one of two different buffers. In particular, the received packets are one of a first type of data packet and a second type of packet. Each one of the first type is stored in a first buffer having a first drop function, while each one of the second type is stored in a second buffer having a second drop function. Each respective drop function specifies a packet drop rate as a function of the average number of packets in its respective buffer. The first drop function has a first average drop rate over a specified time interval, while the second drop function has a second average drop rate over the specified time interval. The first average drop rate and the second average drop rate have a predefined relationship. Accordingly, if the two drop rates do not comply with the predefined relationship, then at least one of the two average drop rates are modified.
In illustrative embodiments, the first buffer and second buffer each have respective first and second packet withdrawal rates that specify the rate that the packets are withdrawn from the respective buffers. In such case, the two average drop rates may be modified by changing at least one of the first packet withdrawal rate and the second packet withdrawal rate. In other instances, the average drop rates may be modified by modifying the second average drop rate as a function of the average number of packets stored in the first buffer.
The first and second drop functions each may have respective start and end points. The start and end points of the first drop function are respectively referred to herein as the first start point and the first end point, while the start and end points of the second drop function are respectively referred to herein as the second start point and the second end point. In such case, the predefined relationship may specify that the first average drop rate is at the first start point whenever the second average drop rate is at the second start point. In a similar manner, the predefined relationship may specify that the first average drop rate is at the first end point whenever the second average drop rate is at the second end point.
In other embodiments, the first drop function defines a first curve connecting the first start point with the first end point, while the second drop function defines a second curve connecting the second start point and the second end point. The predefined relationship in such case may specify that the first average drop rate moves along the first curve at a first rate, while the second average drop rate moves along the second curve at a second rate. The first and second rates may be constant. In some embodiments, the first and second rates are different.
The first and second packet types may be any type of packet known in the art. For example, the first packets may be loss sensitive packets (i.e., packets that generally tolerate packet delay better than data loss), while the second packets may be delay sensitive packets (i.e., packets that generally tolerate data loss better than packet delay).
In accordance with another aspect of the invention, an apparatus and method of processing a received packet for transmission across a network first determines the type of the packet. The packet can be one of two types, such as a delay sensitive packet or a loss sensitive packet. The packet is added to a loss sensitive buffer if the packet is determined to be a loss sensitive packet. Conversely, the packet is added to a delay sensitive buffer if it i
Firoiu Victor
Guo Yang
Zhang Xiaohui
Lin Wen-Tai
Nortel Networks Limited
Steubing McGuinness & Manaras LLP
LandOfFree
Method and apparatus of processing packets having varying... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus of processing packets having varying..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus of processing packets having varying... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3359702