System and method for achieving accelerated throughput

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application is a divisional of U.S. application Ser. No. 12/193,345 filed Aug. 18, 2008, which is a continuation-in-part of U.S. application Ser. No. 10/912,200, filed Aug. 6, 2004, the contents of which are incorporated herein by reference in their entirety.

FIELD OF THE INVENTION

0002The present invention relates to communication data networks. More specifically, the present invention relates to systems and methods for increasing the throughput of data transmissions through a transport network as seen from the edge of the transport network.

BACKGROUND OF THE INVENTION

0003Most, if not all, transport networks are packet based networks that break up data streams into smaller packets of data which are then transmitted from a first source network, or endpoint, to a third destination network, or endpoint, via a second transport network. However, due to congestion and other network limitations, not all packets successfully arrive at the destination network. What matters to the source and end destination networks is the performance of the transport network. The transport network must, from the point of view of the applications at the end networks, ideally be perfect with no lost packets. However, it would be preferred if such performance could be had for a price lower than the usual costs of leasing high performance transport networks.

0004Accordingly, there is a need for systems and methods, which can be used with low cost communications transport networks to provide end network applications with a high performance view of the transport network.

0005Approaches have been tried to address the above situation. In one approach, custom protocol stacks are installed at the endpoints to improve the response to loss and latency. However, this approach requires that both end networks communicate according to the same custom protocol, which generally requires extensive reprogramming.

0006Another approach uses network elements that intercept standard protocols and send protocol responses on behalf of a far-end element. Custom protocols are then used between the intercepting network elements. This approach is limited to TCP/IP applications and adds complexity, especially in regards to troubleshooting network problems.

SUMMARY OF THE INVENTION

0007In a first aspect, there is provided a method of accelerating data communications over an unreliable network. The method comprises providing encoding components associated with each of two endpoints to a communication. An encoded channel between the respective encoding components is then established for a communication session between the endpoints. A data packet related to the communication session is then intercepted at one of the encoding components. The data packet is segmented and marked to provide encoded data segments for transmission to the other of the encoding components. The encoded data segments and at least one extra segment are then transmitted to the other of the encoding components over the encoded channel, where they are decoded and reassembled to recreate the data packet. The reassembled data packet is then transmitted from the other of the encoding components to its respective endpoint. The encoded channel can be torn down if no further packets are transmitted within a predetermined timeout period.

0008According to an embodiment, establishing the encoded channel can comprise detecting a message originating from one of the two endpoints and destined to the other of the two endpoints; storing information uniquely identifying the communication session; detecting a reply to the message, and matching it to the previously stored information identifying the communication session; intercepting the reply; marking the reply to indicate that the endpoint replying to the message is enabled to segment and encode data packets according to a protocol known to both encoding components; forwarding the marked reply to the endpoint originating the message; and exchanging control messages to establish an encoded channel between the encoding components.

0009According to another embodiment, establishing the encoded channel comprises detecting a message originating from one of the two endpoints and destined to the other of the two endpoints; storing information uniquely identifying the communication session; detecting a reply to the message, and matching it to previously stored information identifying the communication session; intercepting the reply prior to delivery to the endpoint originating the message; determining if the reply has been marked to indicate that the endpoint replying to the message is enabled to segment and encode data packets according to a protocol known to both encoding components; and transmitting control messages to establish an encoded channel between the encoding components. Marking the reply can comprise setting an option in an IP header, or setting an identification field to a known value.

0010In yet another embodiment, establishing the encoded channel comprises detecting control messages within one communication session that establish a related communication between the two endpoints according to a known protocol, the control messages including an identification of the related communication sessions's originating and destination ports; and creating an encoded channel in response to the detected control messages. Intercepting the control messages can, for example, comprise applying deep packet analysis to the control message. This embodiment can be used, for example, for RTSP and H.323 communications.

0011Segmenting and packaging the data packet can comprise segmenting the data packet into data segments in accordance with a predetermined encoding rate, or segmenting the data packet into data segments in accordance with a dynamically adjusted encoding rate. The dynamically adjusted encoding rate can be determined by monitoring loss rates for each of a plurality of communication sessions; determining an average loss rate in accordance with the loss rates of each communication session; communicating a loss rate of the communication session and the average loss rate to the other of the two endpoints to permit the other of the two endpoints to adjust its encoding rate. Segmenting and packaging the data packet can further comprise modifying a header of the data packet and appending modified headers to each of the encoded data segments. Modifying the headers can comprise, for example, modifying a sequence number of a TCP header. Identifying information, such as a serial number, for each segment derived from a given data packet can also be added to each segment.

0012In a further aspect, there is provided a method of setting an encoding rate for encoding data for accelerated data communication across an unreliable network. The method comprises establishing an encoded channel for each of a plurality of communication sessions, and monitoring loss rates of each communication session. An average loss rate is also determined in accordance with the loss rates of each communication session. The loss rate of a communication session and the average loss rate are communicated to a respective endpoint to permit the endpoint to adjust its encoding rate to reduce its respective loss rate. Monitoring the loss rates can comprise observing loss rates, and receiving reported loss rates.

0013A further aspect provides a method for streaming video or audio data, or for encoding unidirectional communication sessions, such as over Real-Time Streaming Protocol (RTSP) or between H.323 endpoints. The method comprises providing encoding components at a client and at a server. A message destined to a default port is detected at the encoding components, and parsed using deep packet analysis to determine a session identification for the message. A reply to the message is then detected at the encoding components, and parsed to determine communication ports allocated for use in respect of the communication session. Subsequent data packets are then inspected to determine their originating and destination ports. Each data packet having originating and destination ports that match the allocated communication ports is segmented and marked to provide encoded data segments for transmission to the client. The data packet is decoded and reassembled, based on the received encoded data segments at the encoding component associated with the client. In an embodiment, the deep packet analysis can be achieved using a regex function.

0014Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of example only, with reference to the attached Figures, wherein:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an environment in which the invention may be practiced;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating the components in a server used in <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating the components in another server used in <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart illustrating the steps executed when first data units are received and transformed into second data units for transmission to the transport network;

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating the steps executed when second data units are received from the transport network and transformed into first data units for transmission to an end network;

<figref idref="DRAWINGS">FIG. 6</figref> illustrates an exemplary system and a connection negotiation protocol according to an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 7</figref> illustrates a generic segmentation and encoding of a packet according to the present invention;

<figref idref="DRAWINGS">FIG. 8</figref> shows an exemplary segmentation and encoding of a packet according to an embodiment of the present invention; and

<figref idref="DRAWINGS">FIG. 9</figref> shows an environment in which loss statistics can be determined.

DETAILED DESCRIPTION

0025Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a block diagram of an environment in which the invention may be practiced is illustrated. A first endpoint <b>10</b> communicates, through a network <b>20</b>, with a second endpoint <b>30</b>. The first endpoint <b>10</b> and the network <b>20</b> communicate through an encoding/decoding component <b>40</b>, while the network <b>20</b> communicates with the second endpoint <b>30</b> through an encoding/decoding component <b>50</b>. The encoding/decoding components <b>40</b> and <b>50</b>, hereafter referred to as encoding components, can be resident at the endpoints, or in an intermediate device, such as a server. The first and second endpoints <b>10</b> and <b>30</b> can be terminals, such as personal computers connected through a modem, local or wide-area networks, or other devices or systems having access to the network <b>20</b>. The network <b>20</b> can be, for example, the Internet or other communications network.

0026As used herein, a data unit is any unit of data that can be used to transmit data digitally over a network. Such data units can take the form of packets, cells, frames, or any other such units, provided the data is encapsulated within the unit, or carried as a payload. The term data unit is applicable to any and all packets and frames that implement specific protocols, standards, or transmission schemes. Typically, a header, carrying routing, control and identification information, is added to the data payload.

0027The present system provides a means for insulating the endpoints from the vagaries of the network <b>20</b>. The encoding components <b>40</b> and <b>50</b> are provided with means to insulate the endpoints <b>10</b> and <b>30</b> from the network <b>20</b> by handling the encoding and decoding of data units, and their transmission through the network <b>20</b>. The endpoints <b>10</b> and <b>30</b> can communicate using any protocol, as can the encoding components <b>40</b> and <b>50</b>. The encoding components <b>40</b> and <b>50</b> receive original data units in one protocol from the endpoints <b>10</b> and <b>30</b>, and encode the original data units by subdividing them into preferably smaller data units, creating extra data units that can be used to recreate or reconstruct the original data units in the event that some of the data units transmitted through the transport network are lost, and repackaging the subdivided and extra data units according to the present protocol prior to transmitting them through the transport network.

0028Once the data units transmitted through the transport network <b>20</b> are received at the encoding component associated with the far endpoint, the original data units from the originating endpoint are recreated or reconstructed. This recreation or reconstruction can be done by reordering the received data units, if necessary, and, if some data units were lost during transmission, using the extra data units to recreate missing data units. In the event the extra data units received are insufficient to recreate the original data units, the receiving encoding component can optionally request a re-transmission of the data units previously sent.

0029For ease of explanation, data units originating from or received at the endpoints will be referred to as first data units, or packets, and as being of a first type of data unit. Data units being transmitted across and/or received from the transport network will be referred to as second data units, or segments and as being of a second type of data unit. The second data units are also referred to as encoded data units.

0030<figref idref="DRAWINGS">FIG. 2</figref> shows an exemplary embodiment of modules necessary to implement the present invention within encoding component <b>40</b>, and their respective data flows. The modules can be resident in a single device, or can be distributed amongst several devices. As can be seen, encoding component <b>40</b> has a first interface <b>60</b>, a second interface <b>70</b>, a reassembly module <b>80</b>, and a segmentation module <b>90</b>. The first interface <b>60</b> sends and receives first data units to and from an endpoint <b>10</b>. The second interface <b>70</b> of the server <b>40</b> sends and receives second data units to and from the transport network <b>20</b>.

0031The reassembly module <b>80</b> receives second data units from the second interface <b>70</b> and produces first data units for transmission to the first network <b>10</b> by way of the first interface <b>60</b>. The segmentation module <b>90</b>, on the other hand, receives first data units from the first interface <b>60</b> and produces second data units for transmission to the transport network <b>20</b> by way of the second interface <b>70</b>.

0032Once the second data units have been transmitted through the transport network, they are received by the encoding component at the other endpoint. To illustrate this, <figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary embodiment of the modules and data flow of encoding component <b>50</b>, which communicates with the transport network and endpoint <b>30</b>.

0033The modules in the encoding component <b>50</b> are the same as those in encoding component <b>40</b> and, in fact, have the same functions. The second interface <b>70</b>A in encoding component <b>50</b> also communicates with the transport network and sends and receives second data units. The first interface <b>60</b>A also communicates with an endpoint (in this case the endpoint <b>30</b>) and sends and receives first data units. The reassembly module <b>80</b>A receives second data units and produces first data units while the segmentation module <b>90</b>A receives first data units and produces second data units.

0034As noted above, first data units are the data units used by the end networks, while second data units are used by the transport network and the encoding components <b>40</b>, <b>50</b> when transmitting data to and from each other. The second data units are derived from the first data units. The payload of the first data units can be divided into smaller units and each smaller unit can be the payload in a second data unit. As such, each second data unit can be smaller than the original first data unit from which it was derived. As an example, a 10 kB first data unit may be subdivided into five 2 kB units. These may be the payload of five second data units, each of which may be smaller than 10 kB. This function of creating second data units from first data units is accomplished by the segmentation modules <b>90</b>, <b>90</b>A.

0035To assist in recreating the original first data unit from which the second data units were derived from, the segmentation module also creates extra second data units. These extra second data units can be derived from the first and second data units. The extra second data units assist the reassembly modules <b>80</b>, <b>80</b>A in recreating or reassembling the original first data unit in the event one or more second data units are lost during their transmission through the transport network.

0036The extra second data units can take many forms. In perhaps the simplest embodiment, the extra second data units are merely copies of selected second data units previously sent. As an example, if a first data unit is divided or segmented into four second data units (e.g. DU<b>1</b>, DU<b>2</b>, DU<b>3</b>, DU<b>4</b>), then the extra second data units could be copies of DU<b>2</b> and DU<b>3</b>. As such, if DU<b>2</b> or DU<b>3</b> are lost during the transmission, then the original first data unit can still be recreated. The number and identification of the second data units that are duplicated can be predetermined, or left to the discretion of the system administrator. More redundancy can be built in to the system by including more duplicate second data units, or vice versa for less redundancy, depending on the actual or expected degree of loss in the network <b>20</b>. In the simplest case, all the second data units can be duplicated to ensure that, in essence, two copies of each second data unit are sent to the destination encoding component.

0037Parity data units can also be used as the second extra data units. As is well known in the art, a parity data unit can be created using the XOR function. The bits of the different second data units created from the original first data unit can be XOR'd to result in bit values which can be stored in an extra second data unit. If any one of the second data units (not including the extra second data unit) is lost during transmission, the other received second data units and the extra second data unit can be used to recreate the lost second data unit. Performing an XOR function on the received second data units and the extra second data unit will recreate the missing second data unit.

0038It should be noted that the extra second data units may be encoded using other erasure correcting codes. As an example, if n second data units are generated for a single first data unit, m extra second data units may be generated to allow the lost second data units to be recreated. As noted above, the m extra second data units may be viewed as “redundant” second data units and, if mere duplication is used, m≦n with complete duplication being achieved at m=n. However, if erasure correcting codes are used, with m=2, it is possible to encode the redundant information in such a way that any two second data units can be lost and the reassembly modules can still reconstruct the lost second data units. Well-known methods and coding techniques such as Reed-Solomon, Forward Erasure Correction techniques, and Bose-Chaudhuri-Hochquenghem (BCH) codes, and a multitude of others may be used.

0039While the extra second data units should assist in counteracting the effects of losing some second data units, losing too many second data units cannot be completely compensated for. As such, losing a number of second data units past a threshold level can optionally cause the reassembly modules to request a re-transmission of a package or group of second data units. As an example, if the extra second data units can recover from a 25% loss of data units and there are four second data units generated from a single first data unit, then the loss of a single second data unit would not trigger a re-transmission request. However, with the loss of two second data units (i.e. a 50% loss) the reassembly module could request a re-transmission. If re-transmission is enabled, the re-transmission threshold is ideally related to the error or loss-correcting capability of the coding used for the extra or redundant second data units. The reassembly modules can keep track of the number of second data units received for each first data unit that has been segmented, as the reassembly modules will need to properly sequence the payloads of the second data units.

0040As can be noted from the above, the reassembly modules <b>80</b> and <b>80</b>A decode and reassemble the second data units received to form the original first data units. The second and extra second data units received are tracked to determine if a sufficient number have been received to recreate the original first data unit. If a sufficient number have not been received, retransmission can optionally be requested. If some second data units have been lost, then the reassembly modules can recreate or reconstruct the missing second data units. As noted above, this process depends upon the coding used and the overall strategy employed. Such decoding and error correction processes are well known to those versed in this art.

0041Once the required number of second data units has been received, their payloads are extracted and used to reconstruct the original first data unit from which the second data units were derived. This may be as simple as concatenating the payloads of the second data units to result in the reconstructed first data unit. However, as noted above regarding the decoding, the reconstruction process will depend upon the process used to segment or divide the original first data unit. Once the original first data unit is reconstructed, it can be forwarded to the appropriate interface communicating with the receiving endpoint.

0042Regarding the segmentation modules, these modules perform the task of segmenting or dividing the first data units and “repackaging” the segments into second data units. The segmentation modules also encode the extra second data units as discussed above. The second data units, both those derived from the first data unit and the extra second data units, are then passed on to the interface module, which communicates with the transport network. To facilitate the optional re-transmission of second data units, the segmentation module can also buffer second data units. As an example, if five first data units have been segmented into twenty second data units and five extra second data units, the segmentation module can buffer the last three sets of second data units corresponding to the last three first data units encoded. Thus, twelve second data units and three extra second data units would be buffered by the segmentation module.

0043The segmentation module can also be configured to transmit second data units in an interleaved manner, to spread the risk of losing multiple second data units across different segmented first data units. Thus, instead of sequentially sending groups of second data units such that each group corresponds to a single first data unit, second data units from different first data units can be interleaved with one another. To illustrate, it can be assumed that first data units A, B, and C are respectively segmented into second data units DU-A<b>1</b>, DU-A<b>2</b>, DU-A<b>3</b>; DU-B<b>1</b>, DU-B<b>2</b>, DU-B<b>3</b>; DU-C<b>1</b>, DU-C<b>2</b>, and DU-C<b>3</b>. Instead of sending these second data units grouped according to their respective first data units, they can be interleaved. If second data units are sent in groups of three data units, then the first group can be DU-A<b>1</b>, DU-B<b>1</b>, and DU-C<b>1</b>. Another group can be DU-A<b>2</b>, DU-B<b>2</b>, and DU-C<b>2</b>, and so on. Using this scheme, if a group is lost, then a whole first data unit is not lost—only one third of the three first data units is lost. Depending on the coding and strategy employed, this type of loss may be recoverable.

0044An exemplary method according to the present invention, as implemented in one of encoding components <b>40</b> and <b>50</b>, is shown in <figref idref="DRAWINGS">FIG. 4</figref>. The process begins, with step <b>100</b>, by receiving a first data unit from the source endpoint. After being received, the first data unit is then divided or segmented (step <b>110</b>) and the segments are packaged into second data units (step <b>120</b>). Once the second data units are created, the extra or redundant second data units are encoded and created (step <b>130</b>). The second data units can then be optionally buffered (step <b>140</b>) and transmitted to the transport network (step <b>150</b>). The method then returns to step <b>100</b> via connector A. If re-transmission is enabled, an optional check for a re-transmission request can be made (step <b>160</b>) asynchronously. If such a request is received, then the decision flow returns to step <b>150</b>, and the requested second data units, previously buffered in optional step <b>140</b>, can be transmitted.

0045<figref idref="DRAWINGS">FIG. 5</figref> shows an exemplary embodiment of steps executed by an encoding component receiving second data units from the transport network. The process begins at step <b>180</b> as the server receives second data units from the transport network. Decision <b>190</b> then determines if all the second data units have been received to reconstruct the first data unit from which the second data units were derived. If all the second data units have been received, then the original first data unit is recreated at step <b>200</b>. Once the first data unit have been recreated, the recreated data unit is transmitted to the destination endpoint (step <b>205</b>) and the control flow moves back to step <b>180</b> by way of connector D.

0046Returning to decision <b>190</b>, if not all the second data units have been received, then a decision is made to determine if extra second data units have been received (step <b>220</b>). If no extra second data units have been received, re-transmission can be optionally requested (step <b>230</b>). After the optional re-transmission request, the control flow returns to step <b>180</b> by way of connector D. If extra second data units have been received, decision <b>240</b> determines if sufficient extra second data units and second data units have been received to reconstruct the original first data unit. If an insufficient number have been received, the original packet can be dropped, or, optionally, the control flow can return, as indicated by connector C, to step <b>230</b>: requesting a re-transmission. If a sufficient number of second data units and extra second data units have been received, then the extra second data units can be used to recreate or reconstruct the missing second data units (step <b>260</b>). Connector B then returns the control flow to step <b>200</b>.

0047Some specific examples of implementation will aid in understanding the operation of the present system and method. <figref idref="DRAWINGS">FIG. 6</figref> shows an exemplary system having endpoints A and B. Endpoint A communicates with a network <b>300</b>, such as the Internet, through an encoding component <b>302</b>. Endpoint B is also in communication with the network <b>300</b> through an encoding component <b>304</b>. Encoding components <b>302</b> and <b>304</b> include the interfaces, segmentation and reassembly modules described in relation to <figref idref="DRAWINGS">FIGS. 2 and 3</figref>, and can be implemented wholly in software or can be implemented as pre-programmed hardware units, other related software, or as a combination of hardware and software components. An Ethernet, or other suitable connection, can be used to connect each endpoint to its respective encoding component.

0048For the purposes of this example, it is assumed that a bidirectional communication is occurring between endpoints A and B, and that endpoint A initiates the communication. The present communication protocol is invisible to both endpoints A and B; all functionality resides in the encoding components <b>302</b> and <b>304</b>. To set up a session between endpoints A and B, and to determine if both endpoints are associated with encoding components to permit communication in accordance with the present protocol, the connection negotiation protocol illustrated in <figref idref="DRAWINGS">FIG. 6</figref> can be used. Endpoint A sends a packet P destined to endpoint B. The packet P and its destination are detected or noticed (<b>306</b>) by encoding component <b>302</b>, and encoding component <b>302</b> stores information uniquely identifying the communication session. Packet P is also detected or noticed (<b>308</b>) by encoding component <b>304</b>. Encoding component <b>304</b> stores information uniquely identifying the communication session (<b>310</b>) related to the packet and sends the packet to endpoint B. When endpoint B sends a reply packet R to endpoint A, the reply packet R is intercepted by encoding component <b>304</b>, matched with the previously stored information identifying the communication session and marked (<b>312</b>). The information uniquely identifying the communication session can be, for example, the source IP address, the destination IP address, the protocol contained within the IP packet (e.g. UDP or TCP), and the source and destination ports. For Ethernet frames, the VLAN ID can also be used.

0049The marked packet R^mis used to signal to encoding component <b>302</b> that encoding component <b>304</b> is capable of receiving and sending packets segmented and encoded according to the present invention. Marking the packet can consist of, for example, setting an option in the IP header of the packet, and/or setting the IP identification field to a known value. Routers and other devices in the public network <b>300</b> may leave the IP identification field unchanged during transmission. Other suitable marking or signaling schemes, such as setting the IP address flag in the timestamp, can be used, provided that they are preferably non-destructive, and non-disruptive to devices that are not capable of communication in accordance with the present protocol.

0050Encoding component <b>304</b> then forwards the marked packet R^mto endpoint A, via the public network <b>300</b>. The marked packet R^mis detected by encoding component <b>302</b>, which updates the previously stored information identifying the communication session (<b>316</b>), and sends the packet to endpoint A. The encoding component <b>302</b> can optionally remove the mark prior to forwarding the packet to endpoint A. When endpoint A sends another packet P₂destined to endpoint B, encoding component <b>302</b> matches (<b>318</b>) the packet P₂with the previously stored information identifying the communication session. Recognizing that endpoint B is provided with an encoding component enabled to communicate in accordance with the present protocol, encoding component <b>302</b> sends a “hello” message in addition to forwarding the packet P₂.

0051On receipt of the “hello” message from encoding component <b>302</b>, encoding component <b>304</b> replies with a “hello” reply. Encoding component <b>302</b> then sends a reply acknowledgment (“reply back”) to encoding component <b>304</b>, and begins to segment and encode data packets destined for endpoint B using the present protocol. When component <b>304</b> receives the reply acknowledgment from component <b>302</b>, it also begins to segment and encode data packets destined for endpoint A to provide the second data units previously described. The encoded channel between encoding component <b>302</b> and <b>304</b> is thus successfully automatically detected and negotiated. The encoded channel can be used to carry both data and control information. Once an encoded channel has been negotiated between two encoding components enabled to use the present protocol, segmented and/or encoded messages can now be sent and received. The encoded channel remains active until a predetermined timeout period has elapsed during which the encoding components fail to receive any further packets. Both sides then tear down the encoded channel. Other methods for negotiating the encoded channel between two endpoints are also contemplated. For example, the encoded channel can be negotiated through a pre-existing control channel between the endpoints to the communication.

0052It should be noted that all communication between the endpoints and the components <b>302</b> and <b>304</b> occurs over the established or existing communication channel. The channel can implement known communication protocols, such as Universal Datagram Protocol (UDP) and Transmission Control Protocol (TCP), both over IP. If the connection is a UDP connection, messages according to the present invention are inserted directly into the UDP data payload.

0053If sending data over an existing TCP connection, the original TCP header can be appended to each segment, with the sequence numbers modified. Thus, the source port and destination ports remain the same. The first segment is given the sequence number of the original packet, but subsequent segments are provided with new sequence numbers. In a presently preferred embodiment, an encoded or extra segment re-uses a sequence number of one of its related segments. This permits the extra segment to pass through firewalls in the same manner as would a re-transmitted packet. The data offset and checksum remain unchanged, but the flags, or control bits, are modified for all but the initial segment. For non-segmented messages (i.e. control messages), the remaining message bytes immediately follow the modified TCP header. For segmented messages, a segment payload follows the modified TCP header to provide, for example, identifying information, such as a serial number, to identify a segment and its relation to other segments, and to enable reassembly of the original packet. The data payload of the segment then follows.

0054As will be appreciated, a packet marked or created as described above will pass unchallenged through firewalls and Network Address Translation (NAT) translators. Effectively, the encoded channel establishes a control channel between the encoding components <b>302</b> and <b>304</b>, and packets can pass from either end without being recognized or challenged by any intermediate component, such as a firewall or NAT.

0055Segmentation and encoding of a packet according to an embodiment of the present invention will now be described with reference to <figref idref="DRAWINGS">FIG. 7</figref>. To simplify the discussion, headers have been omitted from the original packet and the segmented packets. An original data payload <b>400</b> is received at an encoding component according to the present invention. The original data payload has x bytes, and is segmented into n segments <b>402</b>. Where n is chosen as an integer factor of x, each of the n segments will have x/n bytes, as shown. In addition, m additional segments are created. In the example shown in <figref idref="DRAWINGS">FIG. 7</figref>, m=1 and the additional or extra packet <b>404</b> is a parity segment created by applying an XOR function to one of the n segments.

0056It may not always be possible or desirable to divide the original data payload <b>400</b> into even segments. For example, it may be necessary to pad the last segment to ensure all segments are of equal length where n is not a factor of x. For example, if x=17 and n=2, the nearest integer value to x/n is 9. Segment sizes that are factors of 4 or 8 are generally preferred, thus the segment size in this case is chosen to be the next factor of 4 greater than, or equal to x/n (e.g. 12 bytes). As shown in <figref idref="DRAWINGS">FIG. 8</figref>, the original 17 byte data payload <b>410</b> is segmented into two 12 byte segment payloads <b>412</b> and <b>414</b>. Segment payload <b>412</b> contains the first 12 bytes of the original data payload <b>410</b>, and segment payload <b>414</b> contains the remaining 5 bytes from the original data payload <b>410</b> optionally padded out to 12 bytes. A further extra segment <b>416</b>, which is a parity segment of segment <b>412</b>, forms the final segment in the sequence. It should be noted that all the segments related to a single original packet or frame have the same serial number to permit their identification and reassembly at the receiving end.

0057The encoding rate is determined by both n and m. The encoding rate can be set to predetermined values (e.g. n=2, m=1 as shown in <figref idref="DRAWINGS">FIG. 8</figref>), or can be adjusted based on observed and/or reported network performance for all encoded channels terminating at an encoding component associated with a given endpoint. One method of determining network performance will now be described in relation to <figref idref="DRAWINGS">FIG. 9</figref>. In <figref idref="DRAWINGS">FIG. 9</figref>, endpoint A is communicating with endpoints B, C and D over a public network <b>440</b>. Each of the endpoints is enabled to communicate according to the present protocol. The encoding component (not shown) associated with endpoint A continually monitors the losses it is experiencing in receiving segments from each of the other endpoints. The encoding component can monitor such losses by, for example, maintaining a count of the number of segments it has failed to receive, or by counting the number of resend requests it sends to each of the other endpoints during their respective sessions. A resend request can be sent by endpoint A whenever it detects excess missing segments in a sequence. Endpoint A can also receive details of observed network performance from endpoints B, C, and D. Applying such methods, endpoint A determines that the connections A-B and A-C are good, and are experiencing little loss. However, the collected performance statistics show that the connection A-D is lossy, and endpoint A is experiencing high loss from D. This likely means that there is a local pocket of loss <b>442</b> somewhere between A and D. Endpoint A reports to D that it is experiencing high loss from D, but low loss on average. This allows D to decrease or increase its encoding rate (i.e. decrease or increase n and/or m) to improve the chance that, despite the lossy channel, packets can be recovered at endpoint A from the received segments.

0058The examples described above generally relate to bidirectional communications between endpoints, where negotiation of the encoded channel is feasible and desirable. However, the present invention can also be used in substantially unidirectional, or streaming, applications to accelerate their performance, and in other applications where negotiating the connection between the encoding components is impractical or otherwise undesirable. In such applications, no negotiation is required between the encoding components associated with each endpoint. The encoded channel is established by recognizing call signaling messages, and subsequent deep packet analysis permits messages related to the communication session to be recognized.

0059For example, the encoding/decoding components of the present invention can be used to take advantage of the stateful nature of Real-Time Streaming Protocol (RTSP) to set up and monitor a connection for streaming. The default port for RTSP commands is port <b>554</b>. Therefore, the encoding components of the present invention can analyze packet headers to determine if they are destined to, or originate from, the RTSP default port, and thereby identify RTSP packets. If a RTSP message is detected, the message can be parsed to determine if it contains a SETUP request, a SETUP response, a TEARDOWN request, or a general RTSP response. A SETUP request from a user contains the media stream URL and a local port for receiving RTP data (audio or video). The RTSP server reply confirms the chosen parameters, and provides the server's chosen ports. By parsing the reply from the RTSP server, the encoding components can determine the RTSP session identification assigned to the data stream, the RTSP sequence number for the message, and the RTP ports that have been allocated for the session by the user terminal and the RTSP server. In this way, an encoded channel for streaming can be set up between the encoding components. Subsequent data units between the client and server can then be analyzed, such as by deep packet analysis. If the ports match those set in the SETUP reply, the message can be intercepted for segmentation and encoding, or decoding and reassembly, as described above, without any negotiation to set up the encoded channel.

0060Similarly, for H.323, the encoding components can analyze packets for messages indicating an H.323 call is being set up. For example, the encoding components can detect and do a deep packet analysis on H.225/Q.931 call setup messages and/or H.245 negotiation and path setup messages to identify called and caller data ports that will be used for the associated H.323 session. An encoded channel according to the present protocol can then be set up to intercept and encode the data flow as described above.

0061In the following description, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that these specific details are not required in order to practice the present invention. In other instances, well-known electrical structures and circuits are shown in block diagram form in order not to obscure the present invention. For example, specific details are not provided as to whether the embodiments of the invention described herein are implemented as a software routine, hardware circuit, firmware, or a combination thereof.

0062Embodiments of the invention may be represented as a software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be any suitable tangible medium, including magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to an embodiment of the invention. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described invention may also be stored on the machine-readable medium. Software running from the machine readable medium may interface with circuitry to perform the described tasks.

0063The above-described embodiments of the present invention are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the invention, which is defined solely by the claims appended hereto.