U.S. patent application number 14/695122 was filed with the patent office on 2015-08-20 for system and method for achieving accelerated throughput.
The applicant listed for this patent is LiveQoS Inc.. Invention is credited to Jonathan N. Cressman, Matthew Robert Williams.
Application Number | 20150236813 14/695122 |
Document ID | / |
Family ID | 41268486 |
Filed Date | 2015-08-20 |
United States Patent
Application |
20150236813 |
Kind Code |
A1 |
Williams; Matthew Robert ;
et al. |
August 20, 2015 |
SYSTEM AND METHOD FOR ACHIEVING ACCELERATED THROUGHPUT
Abstract
Systems and methods for transporting data between two endpoints
over an encoded channel are disclosed. Data transmission units
(data units) from the source network are received at an encoding
component logically located between the endpoints. These first data
units are subdivided into second data units and are transmitted to
the destination network over the transport network. Also
transmitted are encoded or extra second data units that allow the
original first data units to be recreated even if some of the
second data units are lost. These encoded second data units may be
merely copies of the second data units transmitted, parity second
data units, or second data units which have been encoded using
erasure correcting coding. At the receiving endpoint, the second
data units are received and are used to recreate the original first
data units.
Inventors: |
Williams; Matthew Robert;
(Kanata, CA) ; Cressman; Jonathan N.; (Ottawa,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
LiveQoS Inc. |
Ottawa |
|
CA |
|
|
Family ID: |
41268486 |
Appl. No.: |
14/695122 |
Filed: |
April 24, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13554498 |
Jul 20, 2012 |
|
|
|
14695122 |
|
|
|
|
13449159 |
Apr 17, 2012 |
|
|
|
13554498 |
|
|
|
|
12959944 |
Dec 3, 2010 |
|
|
|
13449159 |
|
|
|
|
12193345 |
Aug 18, 2008 |
8009696 |
|
|
12959944 |
|
|
|
|
Current U.S.
Class: |
370/470 |
Current CPC
Class: |
H04L 69/166 20130101;
H04L 1/0083 20130101; H04L 1/009 20130101; H04L 1/0001 20130101;
H04L 1/0007 20130101; H04L 69/22 20130101; H04L 1/0057 20130101;
H04L 1/0015 20130101; H04L 1/0068 20130101; H04L 1/1809 20130101;
H04L 1/0072 20130101; H04L 2001/0097 20130101; H04L 12/6418
20130101; H04L 1/0041 20130101; H04L 1/0035 20130101; H04L 1/0026
20130101; H04L 1/0009 20130101; H04L 1/0071 20130101; H04L 1/08
20130101; H04L 69/326 20130101; H04L 1/1812 20130101 |
International
Class: |
H04L 1/00 20060101
H04L001/00; H04L 29/06 20060101 H04L029/06 |
Claims
1-28. (canceled)
29. A method of increasing throughput of data transmissions through
a network in which data transmission units are transmitted between
one of a plurality of sources and one or more of a plurality of
destinations, said method comprising: producing first data
transmission units at a source of said plurality of sources;
segmenting and packaging said first data transmission units
produced at said source to provide a number of second encoded data
transmission units of a smaller size and a number of extra second
encoded data transmission units; transmitting said second encoded
data transmission units and said extra second encoded data
transmission units to a destination of said one or more of a
plurality of destinations over said network; and reassembling said
first data transmission units at said destination by decoding said
received second encoded data transmission units and said extra
second encoded data transmission units; characterized in that at
least one of said number of second encoded data transmission units
and said number of extra second encoded data transmission units is
dynamically adjusted based on at least one of observed and reported
network performance between one or more of said sources and one or
more of said destinations.
30. The method of claim 29, wherein said number of extra second
encoded data transmission units is dynamically adjusted based on a
performance of a data transmission session.
31. The method of claim 30, wherein said performance includes data
transmission units lost during said data transmission session.
32. The method of any one of claims 29, wherein said extra second
encoded data transmission units are derived from said second
encoded data transmission units, or include parity information
based on said second encoded data transmission units, or include
data transmission units with an erasure correcting code.
33. The method of claim 29, wherein said step of segmenting and
packaging comprises: segmenting the first data transmission units
in accordance with a dynamically adjusted encoding rate, wherein
the dynamically adjusted encoding rate is 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; and communicating a loss rate of the
communication session to one of said source and said destination
and the average loss rate to the other one of said source and said
destination to permit the other one of said source and said
destination to adjust its encoding rate.
34. The method of claim 29, wherein said number of second encoded
data transmission units and said number of extra second encoded
data transmission units are based on a number of data transmission
units lost during said data transmission session.
35. The method of claim 29, wherein: said first data transmission
unit is a data packet created at said source, the data packet
created at the source being segmented and packaged to provide a
predetermined number of encoded data segments of smaller size and a
predetermined number of extra encoded data segments, wherein said
number of encoded data segments and number of extra encoded data
segments are dynamically adjusted based on a measured loss rate of
a communication session in which data packets are transmitted
between the source and the destination over the network.
36. A system for increasing throughput of data transmissions
through a network in which data transmission units are transmitted
between one of a plurality of sources and one or more of a
plurality of destinations, said system comprising: a segmenting
module coupled to a source of said plurality of sources for
segmenting first data transmission units produced at said source to
provide a number of second encoded data transmission units of a
smaller size and a number of extra second encoded data transmission
units; a transmission module coupled to said segmenting module for
transmitting said second encoded data transmission units and said
extra second encoded data transmission units to a destination of
said one or more of a plurality of destinations over said network;
and a reassembly module coupled to said destination to reassemble
said first data transmission units produced at said source by
decoding said received second encoded data transmission units and
said extra second encoded data transmission units and to deliver
said first data transmission unit to said destination;
characterized in that at least one of said number of second encoded
data transmission units and said number of extra second encoded
data transmission units is dynamically adjusted based on at least
one of observed and reported network performance between one or
more of said sources and one or more of said destinations.
37. The system of claim 36, wherein said performance includes data
transmission units lost during a data transmission session.
38. The system of claim 36, wherein said extra second encoded data
transmission units are derived from said second encoded data
transmission units, or include parity information based on said
second encoded data transmission units, or include data
transmission units with an erasure correcting code.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application 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
[0002] The 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
[0003] Most, 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.
[0004] Accordingly, 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.
[0005] Approaches 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.
[0006] Another 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
[0007] In 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.
[0008] According 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.
[0009] According 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.
[0010] In 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.
[0011] Segmenting 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.
[0012] In 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.
[0013] A 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.
[0014] Other 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
[0015] Embodiments of the present invention will now be described,
by way of example only, with reference to the attached Figures,
wherein:
[0016] FIG. 1 is a block diagram of an environment in which the
invention may be practiced;
[0017] FIG. 2 is a block diagram illustrating the components in a
server used in FIG. 1;
[0018] FIG. 3 is a block diagram illustrating the components in
another server used in FIG. 1;
[0019] FIG. 4 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;
[0020] FIG. 5 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;
[0021] FIG. 6 illustrates an exemplary system and a connection
negotiation protocol according to an embodiment of the present
invention;
[0022] FIG. 7 illustrates a generic segmentation and encoding of a
packet according to the present invention;
[0023] FIG. 8 shows an exemplary segmentation and encoding of a
packet according to an embodiment of the present invention; and
[0024] FIG. 9 shows an environment in which loss statistics can be
determined.
DETAILED DESCRIPTION
[0025] Referring to FIG. 1, a block diagram of an environment in
which the invention may be practiced is illustrated. A first
endpoint 10 communicates, through a network 20, with a second
endpoint 30. The first endpoint 10 and the network 20 communicate
through an encoding/decoding component 40, while the network 20
communicates with the second endpoint 30 through an
encoding/decoding component 50. The encoding/decoding components 40
and 50, 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 10 and 30 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 20. The network 20 can be, for example, the Internet or
other communications network.
[0026] As 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.
[0027] The present system provides a means for insulating the
endpoints from the vagaries of the network 20. The encoding
components 40 and 50 are provided with means to insulate the
endpoints 10 and 30 from the network 20 by handling the encoding
and decoding of data units, and their transmission through the
network 20. The endpoints 10 and 30 can communicate using any
protocol, as can the encoding components 40 and 50. The encoding
components 40 and 50 receive original data units in one protocol
from the endpoints 10 and 30, 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.
[0028] Once the data units transmitted through the transport
network 20 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.
[0029] For 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] FIG. 2 shows an exemplary embodiment of modules necessary to
implement the present invention within encoding component 40, 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 40 has a first interface 60, a
second interface 70, a reassembly module 80, and a segmentation
module 90. The first interface 60 sends and receives first data
units to and from an endpoint 10. The second interface 70 of the
server 40 sends and receives second data units to and from the
transport network 20.
[0031] The reassembly module 80 receives second data units from the
second interface 70 and produces first data units for transmission
to the first network 10 by way of the first interface 60. The
segmentation module 90, on the other hand, receives first data
units from the first interface 60 and produces second data units
for transmission to the transport network 20 by way of the second
interface 70.
[0032] Once 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, FIG. 3 illustrates an
exemplary embodiment of the modules and data flow of encoding
component 50, which communicates with the transport network and
endpoint 30.
[0033] The modules in the encoding component 50 are the same as
those in encoding component 40 and, in fact, have the same
functions. The second interface 70A in encoding component 50 also
communicates with the transport network and sends and receives
second data units. The first interface 60A also communicates with
an endpoint (in this case the endpoint 30) and sends and receives
first data units. The reassembly module 80A receives second data
units and produces first data units while the segmentation module
90A receives first data units and produces second data units.
[0034] As 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 40, 50 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 90, 90A.
[0035] To 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 80, 80A 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.
[0036] The 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. DU1, DU2, DU3, DU4), then the extra second
data units could be copies of DU2 and DU3. As such, if DU2 or DU3
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 20. 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.
[0037] Parity 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.
[0038] It 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.ltoreq.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.
[0039] While 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.
[0040] As can be noted from the above, the reassembly modules 80
and 80A 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.
[0041] Once 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.
[0042] Regarding 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.
[0043] The 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-A1, DU-A2, DU-A3; DU-B1, DU-B2, DU-B3; DU-C1, DU-C2,
and DU-C3. 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-A1, DU-B1, and DU-C1. Another
group can be DU-A2, DU-B2, and DU-C2, 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.
[0044] An exemplary method according to the present invention, as
implemented in one of encoding components 40 and 50, is shown in
FIG. 4. The process begins, with step 100, by receiving a first
data unit from the source endpoint. After being received, the first
data unit is then divided or segmented (step 110) and the segments
are packaged into second data units (step 120). Once the second
data units are created, the extra or redundant second data units
are encoded and created (step 130). The second data units can then
be optionally buffered (step 140) and transmitted to the transport
network (step 150). The method then returns to step 100 via
connector A. If re-transmission is enabled, an optional check for a
re-transmission request can be made (step 160) asynchronously. If
such a request is received, then the decision flow returns to step
150, and the requested second data units, previously buffered in
optional step 140, can be transmitted.
[0045] FIG. 5 shows an exemplary embodiment of steps executed by an
encoding component receiving second data units from the transport
network. The process begins at step 180 as the server receives
second data units from the transport network. Decision 190 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 200. Once the
first data unit have been recreated, the recreated data unit is
transmitted to the destination endpoint (step 205) and the control
flow moves back to step 180 by way of connector D.
[0046] Returning to decision 190, 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 220). If no extra second
data units have been received, re-transmission can be optionally
requested (step 230). After the optional re-transmission request,
the control flow returns to step 180 by way of connector D. If
extra second data units have been received, decision 240 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 230: 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 260).
Connector B then returns the control flow to step 200.
[0047] Some specific examples of implementation will aid in
understanding the operation of the present system and method. FIG.
6 shows an exemplary system having endpoints A and B. Endpoint A
communicates with a network 300, such as the Internet, through an
encoding component 302. Endpoint B is also in communication with
the network 300 through an encoding component 304. Encoding
components 302 and 304 include the interfaces, segmentation and
reassembly modules described in relation to FIGS. 2 and 3, 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.
[0048] For 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 302 and 304. 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 FIG. 6 can be used.
Endpoint A sends a packet P destined to endpoint B. The packet P
and its destination are detected or noticed (306) by encoding
component 302, and encoding component 302 stores information
uniquely identifying the communication session. Packet P is also
detected or noticed (308) by encoding component 304. Encoding
component 304 stores information uniquely identifying the
communication session (310) 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
304, matched with the previously stored information identifying the
communication session and marked (312). 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.
[0049] The marked packet R.sup.m is used to signal to encoding
component 302 that encoding component 304 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 300 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.
[0050] Encoding component 304 then forwards the marked packet
R.sup.m to endpoint A, via the public network 300. The marked
packet R.sup.m is detected by encoding component 302, which updates
the previously stored information identifying the communication
session (316), and sends the packet to endpoint A. The encoding
component 302 can optionally remove the mark prior to forwarding
the packet to endpoint A. When endpoint A sends another packet
P.sub.2 destined to endpoint B, encoding component 302 matches
(318) the packet P.sub.2 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 302 sends
a "hello" message in addition to forwarding the packet P.sub.2.
[0051] On receipt of the "hello" message from encoding component
302, encoding component 304 replies with a "hello" reply. Encoding
component 302 then sends a reply acknowledgment ("reply ack") to
encoding component 304, and begins to segment and encode data
packets destined for endpoint B using the present protocol. When
component 304 receives the reply acknowledgment from component 302,
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 302 and 304 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.
[0052] It should be noted that all communication between the
endpoints and the components 302 and 304 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.
[0053] If 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.
[0054] As 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 302 and 304, and packets can pass from either end
without being recognized or challenged by any intermediate
component, such as a firewall or NAT.
[0055] Segmentation and encoding of a packet according to an
embodiment of the present invention will now be described with
reference to FIG. 7. To simplify the discussion, headers have been
omitted from the original packet and the segmented packets. An
original data payload 400 is received at an encoding component
according to the present invention. The original data payload has x
bytes, and is segmented into n segments 402. 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 FIG. 7, m=1 and the additional or extra packet 404
is a parity segment created by applying an XOR function to one of
the n segments.
[0056] It may not always be possible or desirable to divide the
original data payload 400 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 FIG. 8, the original 17
byte data payload 410 is segmented into two 12 byte segment
payloads 412 and 414. Segment payload 412 contains the first 12
bytes of the original data payload 410, and segment payload 414
contains the remaining 5 bytes from the original data payload 410
optionally padded out to 12 bytes. A further extra segment 416,
which is a parity segment of segment 412, 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.
[0057] The 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 FIG. 8), 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 FIG. 9. In FIG. 9, endpoint A is communicating with
endpoints B, C and D over a public network 440. 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 442 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.
[0058] The 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.
[0059] For 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 554. 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.
[0060] Similarly, 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.
[0061] In 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.
[0062] Embodiments 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.
[0063] The 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.
* * * * *