U.S. patent application number 16/107138 was filed with the patent office on 2018-12-13 for system and method for a tcp mapper.
The applicant listed for this patent is LiveQoS Inc.. Invention is credited to Miika Anttoni Klemetti, Vijayendran Mahendran, Uri Nebogatov, Mohan Krishna Vemulapali, Matthew Robert Williams.
Application Number | 20180359185 16/107138 |
Document ID | / |
Family ID | 50385074 |
Filed Date | 2018-12-13 |
United States Patent
Application |
20180359185 |
Kind Code |
A1 |
Williams; Matthew Robert ;
et al. |
December 13, 2018 |
SYSTEM AND METHOD FOR A TCP MAPPER
Abstract
A system for congestion control of traffic in a network that
uses Transmission Control Protocol (TCP) includes a plurality of
TCP congestion control programs having one or more parameters, a
plurality of TCP congestion control units running the TCP
congestion control programs, and a TCP mapper adapted to map
incoming TCP traffic flow from a plurality of incoming TCP traffic
flows to the TCP congestion control units based on at least one of
(a) the type of application program from which the incoming TCP
traffic flow originated (b) the type of network for which the
incoming TCP traffic flow is destined, (c) parameters related to
network performance (d) network constraints (e) source of the
incoming TCP traffic flow, and (f) destination of the incoming TCP
traffic flow.
Inventors: |
Williams; Matthew Robert;
(Kanata, CA) ; Vemulapali; Mohan Krishna; (Nepean,
CA) ; Nebogatov; Uri; (Kanata, CA) ; Klemetti;
Miika Anttoni; (Kanata, CA) ; Mahendran;
Vijayendran; (Kanata, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
LiveQoS Inc. |
Ottawa |
|
CA |
|
|
Family ID: |
50385074 |
Appl. No.: |
16/107138 |
Filed: |
August 21, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15297375 |
Oct 19, 2016 |
10079764 |
|
|
16107138 |
|
|
|
|
14157717 |
Jan 17, 2014 |
9503377 |
|
|
15297375 |
|
|
|
|
13799110 |
Mar 13, 2013 |
8711690 |
|
|
14157717 |
|
|
|
|
13644057 |
Oct 3, 2012 |
8630204 |
|
|
13799110 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 47/11 20130101;
H04L 1/188 20130101; H04L 1/1867 20130101; H04L 47/50 20130101;
H04L 1/205 20130101; H04L 1/22 20130101; H04L 1/203 20130101; H04L
47/193 20130101; H04L 47/12 20130101; H04L 69/163 20130101 |
International
Class: |
H04L 12/801 20130101
H04L012/801; H04L 29/06 20060101 H04L029/06; H04L 12/863 20130101
H04L012/863; H04L 1/18 20060101 H04L001/18; H04L 1/20 20060101
H04L001/20; H04L 1/22 20060101 H04L001/22 |
Claims
1-30. (canceled)
31. A method for congestion control of traffic in a network that
uses Transmission Control Protocol (TCP), wherein said traffic
includes one or more TCP traffic flows each using a first TCP
congestion control program, said method comprising: mapping a first
of said one or more TCP traffic flow to a second TCP congestion
control program selected from a plurality of TCP congestion control
programs using a TCP mapper, said second TCP congestion control
program selected based on a measured performance of the
network.
32. The method of claim 31 whereby said TCP mapper makes a
determination whether said first TCP congestion control program is
capable of satisfying a throughput requirements of an application
program originating at said first TCP traffic flow and bases said
mapping on said determination.
33. A system for congestion control of traffic in a network that
uses Transmission Control Protocol (TCP), wherein said traffic
includes one or more incoming TCP traffic flows each using a first
TCP congestion control program, said system comprising: one or more
TCP congestion control programs having one or more parameters, a
TCP mapper to map a first of said one or more TCP traffic flow to a
second TCP congestion control program selected from a plurality of
TCP congestion control programs based on a measured performance of
the network.
34. The system of claim 33 whereby said TCP mapper makes a
determination whether said first TCP congestion control program is
capable of satisfying a throughput requirements of an application
program originating at said first incoming TCP traffic flow and
bases said mapping on said determination.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of and claims
priority to U.S. patent application Ser. No. 13/644,057, filed Oct.
3, 2012, which is hereby incorporated by reference herein in its
entirety.
FIELD OF THE INVENTION
[0002] This invention is directed towards networks that use the
Transmission Control Protocol (TCP).
SUMMARY
[0003] In accordance with one embodiment, a system is provided for
congestion control of traffic in a network that uses Transmission
Control Protocol (TCP), and the traffic includes a plurality of
incoming TCP traffic flows. The system includes a plurality of TCP
congestion control programs having one or more parameters, a
plurality of TCP congestion control units each of which runs one of
the plurality of TCP congestion control programs, and a TCP mapper
adapted to map a first incoming TCP traffic flow from the plurality
of incoming TCP traffic flows to a first one of the plurality of
TCP congestion control units running a first one of the plurality
of TCP congestion control programs. The mapping is based on at
least one of: [0004] (a) the type of application program from which
the incoming TCP traffic flow originated, [0005] (b) the type of
network for which the incoming TCP traffic flow is destined, [0006]
(c) parameters related to network performance [0007] (d) network
constraints, [0008] (e) source of the incoming TCP traffic flow,
and [0009] (f) destination of the incoming TCP traffic flow. [0010]
The incoming TCP traffic may originate from a TCP sending host.
[0011] One implementation includes a TCP sending host that adjusts
the round trip time (RTT) seen by that host, and analyzes
measurements of the parameters related to network performance, the
measurements being performed by at least one of the TCP mapper and
external sensors. The system may perform one or more heuristics and
tune at least one parameter of the first TCP congestion control
program based on results of the one or more heuristics. The
heuristics may include at least one of (a) determining presence and
persistence of congestion, (b) determining goodput as a fraction of
the rate of the traffic transmitted by the TCP host, (c)
determining changes in the one-way delays of traffic transmitted by
the TCP host, and (d) estimating channel capacity using at least
one of (i) inter-packet arrival time, (ii) inter-acknowledgement
message arrival time, (iii) variance of latency of packets within a
burst, and (iv) loss rate of packets within a burst. This system
may also identify the cause of a packet loss event based on
determining of presence and persistence of congestion.
[0012] In a system that includes a TCP sending host, the TCP mapper
may send signals to the TCP host, and at least one of those signals
may repeat re-transmission of a lost packet.
[0013] A method is provided for congestion control of traffic in a
network that uses Transmission Control Protocol (TCP), wherein the
traffic includes one or more incoming TCP traffic flows. The
network includes a plurality of TCP congestion control programs and
a plurality of TCP congestion control units, each TCP congestion
control unit running one of the plurality of TCP congestion control
programs. The method maps an incoming TCP traffic flow from the one
or more incoming TCP traffic flows to a first of the plurality of
TCP congestion control programs using a TCP mapper. The mapping is
based on at least one of [0014] (a) the type of application program
from which the incoming TCP traffic flow originated, [0015] (b) the
type of network for which the incoming TCP traffic flow is
destined, [0016] (c) parameters related to network performance,
[0017] (d) network constraints, [0018] (e) source of the incoming
TCP traffic flow, and [0019] (f) destination of the incoming TCP
traffic flow.
[0020] In one implementation, the TCP mapper is a midstream TCP
proxy.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The invention may best be understood by reference to the
following description taken in conjunction with the accompanying
drawings.
[0022] FIG. 1 shows a typical network with one TCP sending host and
one TCP receiving host.
[0023] FIG. 2 shows the network of FIG. 1, but with a TCP mapper
included.
[0024] FIG. 3 shows the network 103 with TCP mappers 105 and 205 at
the sending and receiving side of the network.
[0025] FIG. 4 shows another embodiment, whereby sending TCP hosts
201A to 201M are connected to one mapper.
[0026] FIG. 5 shows an embodiment, whereby sending host-mapper
combinations 401A to 401K are connected to network 103.
[0027] FIG. 6 shows an example with sending-host mapper
combinations 501A to SOIL wherein combinations 501A to 501K are
single sending host-mapper combinations; and combination 501L is a
multiple sending host-mapper combination.
DETAILED DESCRIPTION OF ILLUSTRATED EMBODIMENTS
[0028] Although the invention will be described in connection with
certain preferred embodiments, it will be understood that the
invention is not limited to those particular embodiments. On the
contrary, the invention is intended to cover all alternatives,
modifications, and equivalent arrangements as may be included
within the spirit and scope of the invention as defined by the
appended claims.
[0029] FIG. 1 shows a typical network, with a TCP sending host 101
sending traffic using TCP over a network 103 to a TCP receiving
host 102. The TCP sending host 101 has a TCP transmission queue
104. Network 103 could be, for example a single wired, 3G, 4G or
Wi-Fi network. In one embodiment, network 103 could further contain
wired, 3G, 4G or Wi-Fi subnetworks.
[0030] FIG. 2 shows the network of FIG. 1, but with a TCP mapper
105 included. The TCP mapper 105 acts as a midstream TCP proxy for
TCP streams that would normally terminate on the TCP receiving
host. The TCP mapper 105 contains a processing system 107. TCP
mapper 105 intercepts incoming TCP traffic flows from the TCP
sending host 101, and the processor 106 within a TCP mapper
processing system 107 maps each incoming TCP traffic flow to one of
the TCP congestion control (CC) units 108-A to 108-N in the TCP
mapper processing system 107. In one embodiment, each CC unit runs
a different congestion control program. In another embodiment, a
subset of the CC units may run the same program, but each CC unit
within that subset can only tune or configure a given subset of
parameters used within the program. In another embodiment, the TCP
mapper processor 106 works together with each CC unit to tune the
parameters available to the CC unit for the corresponding TCP
congestion control program run by the CC unit. Examples of CC
programs are provided below. Each CC unit also has an associated
buffer, 109-A to 109-N as shown in FIG. 2, used to store packets
awaiting transmission. In one embodiment, the TCP mapper 105 has
several sensors (not shown) to, for example, measure parameters
relating to network performance, such as loss, throughput, latency,
bandwidth, jitter and goodput. In another embodiment, the TCP
mapper further uses these parameters to perform analyses. As will
be further detailed below, in another embodiment the TCP mapper
performs mapping based on whether network constraints, for example
prioritization and traffic policing, are being applied in the
network.
[0031] The TCP mapper 105 provides several advantages. The sending
host 101 has to progress through one or more different stages
before reaching the stage corresponding to maximum throughput.
Additionally, the speed of progression through the stages depends
on the round trip time (RTT). In one embodiment, the mapper 105 is
separate but closely located to the sending host 101. In one
embodiment, the RTT between the mapper 105 and sending host 101 is
below a threshold RTT.sub.thresh, which is a fraction of the RTT
between the sending host 101 and the receiving host 102.
RTT.sub.thresh can be set, for example, via analysis of historical
records, calculation, or simulation of network performance. Since
the mapper 105 is positioned close to the sending host 101,
interception by the mapper 105 has the effect of reducing the RTT
seen by the sending host 101, and therefore speeding up the
throughput progression of the TCP sending host 101 through the
various stages before reaching the stage corresponding to maximum
throughput.
[0032] In another embodiment, the TCP mapper adjusts the RTT to a
value which is optimally suited to the requirements of the sending
host 101. For example, the mapper may adjust the RTT so as to
reduce the variance of the RTT seen by the sending host 101.
Alternatively, the mapper may increase the RTT by adding in extra
delays, as some sending host 101 applications perform better when
these applications see increased RTT. This is useful, as some
operating systems limit the amount of unacknowledged data if a low
RTT is measured.
[0033] In a further embodiment, the TCP mapper makes adjustments so
as to control the calculation of RTT. For example, the starting
value and ending value to calculate RTT are adjusted by the mapper
as to avoid any "overhead" of sending and receiving the packets
respectively at the sending host. In another embodiment, the TCP
mapper measures these overheads or communicates with the sending
host to measure these overheads, and subtracts these measures from
the recorded RTT. This gives a truer estimate of the RTT within the
network.
[0034] In another embodiment, the TCP mapper is placed within the
sending host 101, but separate from the sending host 101 TCP
engine. This has the effect of reducing the RTT to nearly zero and
further speeding up the progression of the sending host through the
TCP stages to reach the stage where maximum throughput can be
achieved. In yet another embodiment, the TCP mapper replaces the
sending host 101 TCP engine.
[0035] The TCP mapper 105 can recognize the application from which
the traffic originates, such as, for example, including but not
limited to, file transfer traffic, Remote Desktop Protocol (RDP)
traffic, or streaming traffic. In one embodiment, the TCP mapper
recognizes the originating application by inspecting packet headers
and contents. In another embodiment, the TCP mapper recognizes the
originating application through explicit notification by an
application, end system or other network device.
[0036] In one embodiment, the TCP mapper 105 maps traffic to
corresponding congestion control units, based on the originating
application, and stores the packets from the different applications
in one of the buffers 109A to 109N corresponding to the chosen
congestion control unit.
[0037] In another embodiment, the TCP mapper is able to determine
the type of network that the traffic is destined for, by, for
example, inspecting packet headers or contents to determine
destination, and recognizing the type of network, for example,
wired, 3G, 4G or Wi-Fi that it is destined for. Then, the TCP
mapper maps traffic to CC units 108A to 108N based on the type of
network that the traffic is destined for. For example, there could
be different CC units corresponding to wired, 3G, 4G or Wi-Fi
networks.
[0038] In another embodiment, the TCP mapper is aware of the
congestion control program used by other TCP flows flowing through
a common network device. Then the mapping to CC units 108A to 108N
is dependent upon the congestion control program used by these
other flows. For example, if the TCP mapper needs to map traffic
from an incoming flow, and determines that many of the other
incoming flows are sent by hosts using the TCP Reno program, then
the TCP mapper may map the traffic from the incoming flow to the
TCP CUBIC program.
[0039] The TCP mapper can determine the other congestion control
programs being used in the network in a variety of ways. In one
embodiment, the TCP mapper can correlate congestion window size
evolution of an unknown congestion control program to that of an
existing congestion control program, based on the known behaviour
of the congestion control program.
[0040] In another embodiment, the TCP mapper samples the evolution
of the inflight window, which is the amount of bytes in flight for
a given RTT; and detects that this value is linearly increasing
with time, assuming discrete RTT-sized time increments. Based on
this, the TCP mapper decides with reasonable accuracy that the TCP
RENO congestion control program is being used.
[0041] In another embodiment, the TCP mapper uses higher sampling
rates, to sample the evolution of the inflight window, and
determines that the shape of the curve between loss events is that
of a cubic function, biased in time and amplitude. Based on this,
the TCP mapper decides with reasonable accuracy that the TCP CUBIC
congestion control program is being used.
[0042] In another embodiment, the TCP mapper uses known methods for
identifying congestion control programs based on probing methods
(see e.g. "Identifying TCP Congestion Control Mechanisms using
Active Probing" by S. S. Feyzabadi located at
http://cnds.eecs.jacobs-university.de/courses/nds-2009/feyzabadi-report.p-
df).
[0043] In another embodiment, after deducing the TCP congestion
control program being used by a host, the TCP mapper further
determines whether it is suitable for flows originating from that
host given current observed network conditions. If not, the TCP
mapper maps such flows to a more appropriate congestion control
program.
[0044] In another embodiment, the TCP mapper maps traffic to CC
units 108A to 108N based upon either the source or the destination
of the flow to which the traffic belongs. The TCP mapper is able to
identify the source or the destination by, for example, inspecting
packet headers and contents; or via explicit notification by an
application, end system or other network device.
[0045] In yet another embodiment, the TCP mapper maps traffic to CC
units 108A to 108N based upon measurements of parameters relating
to network performance such as loss, throughput, goodput, latency,
packet jitter and bandwidth. In one embodiment, these parameter
measurements are taken by sensors within the TCP mapper 105.
However, certain parameters may only be measured at the receive
side, so in another embodiment, these network performance are
measured externally, for example, by external sensors at the
receive side, and conveyed to the TCP mapper 105 via either in-band
or out-of-band techniques.
[0046] In another embodiment, the TCP mapper uses these
measurements to perform analyses, and makes mapping decisions based
on the results of these analyses. For example, the TCP mapper could
use these measurements to determine if a network is congested, and
the nature of the congestion, in the following way: When the
aggregate bitrate of all the flows in a given channel reaches the
limits of the channel capacity, the channel is said to be
congested. The persistence of this congestion can be determined by
analyzing the resulting steady-state and mapping out the evolution
of loss and latency over time; as well as the correlation between
the two. In another embodiment, heuristic techniques or heuristics
such as the techniques described above are performed by an external
module. Then, based on the results of these analyses, the TCP
mapper maps traffic to one of the CC units.
[0047] In yet another embodiment, the TCP mapper maps traffic to CC
units 108A to 108N based upon network constraints such as
prioritization of certain types of traffic over other types of
traffic with the network; and the presence of traffic policing. In
one embodiment, the TCP mapper can auto-detect the presence of such
constraints. For example, the TCP mapper is able to detect if
prioritization is being used by looking at various aspects of the
packets such as Internet Protocol Differentiated Services Code
Point (IP DSCP) bits or looking at the priority bits in the Media
Access Control (MAC) headers. The TCP mapper is also able to detect
when a given TCP stream is "application-limited," or in other
words, not utilizing the maximum bandwidth allowed by the current
state of the CC program. By analyzing if the flow in question is
"application limited" or is being limited by prioritization
policies, the TCP mapper can choose an appropriate CC program.
Alternatively, the TCP mapper can be explicitly programmed to take
into account these network constraints. For example, the mapper may
be programmed by a user to recognize that certain types of traffic
will be prioritized over other types of traffic. Similarly,
relevant data can be extracted from policing contracts by a user
and then explicitly programmed into the TCP mapper by a user.
Mapping decisions are then made based on this data.
[0048] In a further embodiment, the TCP mapper maps traffic to CC
units 108A to 108N based upon two or more of [0049] originating
application; [0050] the type of network that the traffic is
destined for; [0051] source of the flow to which the traffic
belongs; [0052] destination of the flow to which the traffic
belongs; [0053] parameters related to network performance [0054]
network constraints
[0055] As explained previously, in one embodiment, each CC unit
runs a different congestion control program. In another embodiment,
a subset of the CC units may run the same program, but each CC unit
within that subset can only tune or configure a given subset of
parameters used within the program. In another embodiment, the TCP
mapper processor 106 works together with each CC unit to tune the
parameters available to the CC unit for the corresponding TCP
congestion control program run by the CC unit.
[0056] The mapping can be carried out in a variety of ways. In one
embodiment, a lookup table can be used to map TCP port numbers to
CC units with a defined default CC unit being used in the case that
no lookup table entry exists. Other lookup tables could map source
and destination IP addresses and other IP and TCP header values to
target CC units. In another embodiment, multiple lookup tables can
be used in order until a match is found.
[0057] As explained previously, each congestion control unit is
able to tune the parameters available to the CC unit for the
congestion control program which is run by the CC unit on the fly,
such that the constraints for each flow type (latency, bandwidth,
jitter) are met. As an example, if the CC unit is using the TCP
CUBIC, the reference time constants and overall scaling factors can
be the adjusted parameters. Multiple tuning approaches can be used.
In one embodiment, tuning can be based on measurements of
parameters relating to network performance such as loss,
throughput, goodput, latency, packet jitter and bandwidth. A lookup
table containing measured network performance-related metrics and
tuning parameters can be used. These metrics can include packet
loss, latency, jitter, throughput, goodput and other measurable
network statistics. In another embodiment, a lookup table relating
internal CC metrics such as buffer fill level and timer values to
tuning parameters can be used. In another embodiment, the TCP
mapper processor 106 co-operates with each CC unit to tune the
parameters available to the CC unit for the corresponding TCP
congestion control program run by the CC unit, such as in the TCP
CUBIC example given above. Initial parameter values can be
calculated based on historical measurements and then further tuned
as new measurements are made.
[0058] In another embodiment, the TCP mapper uses these
measurements to perform analyses, and performs tuning based on the
results of the analyses. As previously explained, the TCP mapper
may, for example, use these measurements to determine if the
network is persistently congested. The TCP mapper can then perform
tuning accordingly.
[0059] In another embodiment, the TCP mapper uses other heuristics
to appropriately tune the parameters. Measures such as achieved
goodput, bottleneck link buffer capacity and channel capacity are
analyzed, and used in such heuristics. The results from use of the
heuristics are utilized to tune the parameters. In one embodiment,
the heuristics are performed by an external module.
[0060] In yet another example, heuristics are used to differentiate
between network loss due to a congestion event and due to a random
event. Referring to the example of congestion, once the onset of a
period of persistent congestion has been identified, it is highly
likely that packet loss events during this period of persistent
congestion are due to congestion rather than random causes, and can
be identified as such. Similarly, during a period of
non-congestion, loss events are more likely to be random events.
Based on the results obtained from applying this heuristic, the
mapper performs tuning of the parameters accordingly. As an
example, in one embodiment if one of the parameters is a congestion
window and the loss event is determined to be a random event rather
than due to congestion, then the mapper sends an instruction to the
CC program to not reduce the congestion window.
[0061] Another example of a heuristic is measuring the rate of the
TCP traffic acknowledged by the receiving host, that is, the
goodput, as a fraction of the rate of the TCP traffic transmitted
by the sending host. This ratio is then referred to a lookup table
to choose an appropriate tuning parameter. This is performed, for
example, to prevent overflow of network buffers. The lookup table
is built, for example, using historical observations, computer
simulations, or by using well-established mathematical
relationships for known traffic arrival processes such as Poisson
processes.
[0062] Another example of a heuristic is using measurements of the
changes in the one-way delays of data transmitted, to estimate the
number of queued packets in a bottleneck link buffer. Similar to
the previous example, the changes in the one-way delays are
referred to a lookup table to estimate the number of queued packets
in a bottleneck link buffer. Such a lookup table is built, for
example, by using historical observations; computer simulations; or
well-established mathematical relationships for known traffic
arrival processes such as Poisson processes. This heuristic assists
in limiting the "bloat" in latency caused by packets waiting in
long queues in bottleneck link buffers.
[0063] A further example of a heuristic is using inter-packet
arrival time to estimate channel capacity. Inter-acknowledgement
message arrival time may also be used to estimate channel capacity.
The variance of latency of packets within a burst may be used to
estimate channel capacity. Loss rate of packets within a burst may
also be used to estimate channel capacity. One or more of: [0064]
Inter-packet arrival time [0065] Inter-acknowledgement message
arrival time [0066] Variance of latency of packets within a burst
[0067] Loss rate of packets within a burst may also be used to
estimate channel capacity. Similar to the previous example, one or
more of these measures can be referred to a lookup table to
estimate the channel capacity. The lookup table is built using, for
example, historical observations, computer simulations, or
well-known mathematical relationships. Such estimations may be used
to ensure that the average traffic rate is appropriately matched to
the estimated link capacity.
[0068] In another embodiment, tuning can be based upon network
constraints, for example, prioritization of certain types of
traffic over other types of traffic within the network. As
explained previously, the TCP mapper is able to auto-detect if
constraints such as prioritization are being used. Alternatively,
the TCP mapper can be explicitly programmed by a user to take
constraints into account when performing mapping. As previously
explained, the mapper can be programmed to take into account the
prioritization of certain types of traffic will be prioritized over
other types of traffic. Similarly, relevant data can be extracted
from policing contracts by a user and then explicitly programmed
into the TCP mapper by the user. Tuning decisions are then made
based on this data.
[0069] In another embodiment, as previously explained, the TCP
mapper is aware of the congestion control programs used by other
TCP flows flowing through a common network device. The mapper is
able to identify congestion control programs using various
approaches, as outlined above. Then, the mapper can perform tuning
based on the other congestion control programs being used in the
network.
[0070] In another embodiment, the mapping to a CC unit for a given
flow could be switched "on the fly" by the TCP mapper 105 based on
network performance measurements. Consider a situation where a flow
is currently mapped to a first CC unit. The mapping can then be
dynamically switched, such that congestion control for traffic
belonging to the same flow will then be handled by a second CC
unit, different from the first CC unit. After the dynamic
switching, the traffic belonging to the flow will be buffered in
the buffer corresponding to the second CC unit. This can be
accomplished by copying the data from the buffer of the first CC
unit to the buffer of the second CC unit and using the latest known
metrics to calculate the initial settings for the parameters
available to the second CC unit. In one embodiment, the TCP mapper
processor 106 dynamically switches the flow mapping to the second
CC unit and copies the traffic belonging to the flow from the first
CC unit to the buffer of the second CC unit. The second CC unit
calculates the initial settings for the parameters available to it.
In a further embodiment, the TCP mapper processor 106 co-operates
with the second CC unit to calculate the initial settings for the
parameters.
[0071] Another approach is for the TCP mapper processor 106 to
co-operate with the first CC unit to tune the parameters available
to the first CC unit for the CC program being run by the first CC
unit; while the TCP mapper processor 106 concurrently co-operates
with alternate CC units to tune available parameters for the CC
programs run by the alternate CC units. This way, the correct
settings for the parameters are already in place when a switch to
an alternate CC unit is desired.
[0072] Congestion control program parameter tuning is performed
based on, for example, network performance measurements such as
loss, throughput, goodput, latency, packet jitter and bandwidth. As
explained previously, in one embodiment, these network performance
measurements are taken by sensors within the TCP mapper 105. As
explained previously, certain network performance measurements may
only be measured at the receive side, so in another embodiment,
these network performance measurements are measured externally, for
example, by external sensors at the receive side, and conveyed to
the TCP mapper 105 via either in-band or out-of-band
techniques.
[0073] In one embodiment, the TCP mapper processor 106 collects the
results from the sensors, and distributes these results to the
individual CC units 108A to 108N. At each CC unit, parameters for
the TCP congestion control program run by the unit are tuned on the
fly by the CC unit based on different application requirements and
parameters related to network performance. In another embodiment,
the TCP mapper processor 106 works together with each CC unit to
tune the parameters for the corresponding TCP congestion control
program run by the CC unit.
[0074] Various types of TCP congestion control programs can be run.
In one embodiment, one of the CC units 108A to 108N runs the TCP
Hybla CC program. Then, traffic to be transmitted to networks with
long RTTs for example, much greater than 500 ms, is directed to the
buffer associated with the TCP Hybla CC unit, and the corresponding
TCP Hybla CC unit will be used for congestion control for this
traffic. The operation and tuning of relevant parameters in the TCP
Hybla CC unit has been well documented elsewhere (see, for example,
C. Caini et al, "TCP Hybla: a TCP Enhancement for Heterogeneous
Networks," in International Journal of Satellite Communications and
Networking, John Wiley & Sons, Volume 22, Number 5, pp 547-566,
September 2004)
[0075] In another embodiment, one of the CC units 108A to 108N runs
the TCP CUBIC congestion control program. Then, for example,
traffic to be transmitted to a high speed network, is directed to
the buffer associated with TCP CUBIC, and the corresponding TCP
CUBIC CC unit will be used for congestion control for this traffic.
The operation and tuning of relevant parameters in the TCP CUBIC CC
unit has been well documented elsewhere (see, for example, Ha et al
"CUBIC: A New TCP-Friendly High-Speed TCP Variant" ACM SIGOPS
Operating System Review, Volume 42, Issue 5, July 2008,
Page(s):64-74, 2008.)
[0076] In another embodiment, one of the CC units 108A to 108N runs
the Data Center TCP (DCTCP) congestion control program. Then, for
example, traffic to be transmitted to a data center network; or
traffic from applications requiring low latency and high bandwidth;
is directed to the buffer associated with DCTCP. The corresponding
DCTCP CC unit will be used for this traffic. The operation and
tuning of relevant parameters in the DCTCP CC unit has been well
documented elsewhere (see, for example, Alizadeh et al "DCTCP:
Efficient Packet Transport for the Commoditized Data Center",
Proceedings of SIGCOMM 2010)
[0077] In another embodiment, one of the CC units 108A to 108N runs
the TCP Westwood+ congestion control program or the TCP Westwood CC
program. Then, for example, traffic to be transmitted to a wireless
network is directed to the buffer associated with TCP Westwood+ or
TCP Westwood. The corresponding TCP Westwood+ CC unit will then be
used for congestion control for this traffic. The operation and
tuning of relevant parameters has been well documented elsewhere
(see, for example, Mascolo et al "TCP Westwood: Bandwidth
Estimation for Enhanced Transport over Wireless Links" Proc. of the
ACM Mobicom 2001, Rome, Italy, July 16-21 2001; or Grieco et al
"Performance evaluation and comparison of Westwood+, New Reno and
Vegas TCP congestion control" ACM Computer Communication Review,
April 2004, Vol. 34(2))
[0078] In another embodiment, one of the CC units 108A to 108N runs
the TCP Illinois congestion control program or the TCP Illinois CC
program. Then, for example, traffic to be transmitted to a high
speed, long RTT network is directed to the buffer associated with
TCP Illinois. The corresponding TCP Illinois CC unit will then be
used for congestion control for this traffic. The operation and
tuning of relevant parameters has been well documented elsewhere
(see, for example, Liu et al, "TCP-Illinois: A loss and delay-based
congestion control algorithm for high-speed networks" Pages
417-440, Performance Evaluation 65 (2008))
[0079] In another embodiment, one of the CC units 108A to 108N runs
the FAST TCP CC program. Then, for example, traffic from
applications which are latency and jitter sensitive; or to be
transmitted to a high-speed, long RTT network; is directed to the
buffer associated with FAST TCP. The corresponding FAST TCP CC unit
will then be used for congestion control for this traffic. The
operation and tuning of relevant parameters has been well
documented elsewhere (see, for example, Wei et al "FAST TCP:
Motivation, Architecture, Algorithms, Performance", IEEE/ACM
Transactions on Networking, vol. 14. no. 6 Dec. 2006)
[0080] Other types of CC programs can be run on the CC units. For
example, a CC program which dynamically modifies window sizes based
on measured latency can also be run on one of the CC units 108A to
108N. Then, for example, traffic from applications such as Remote
Desktop Protocol (RDP) can be directed to the corresponding buffer,
and the CC unit will be used for congestion control for this type
of traffic.
[0081] In one embodiment, the TCP mapper 105 can also perform flow
adaptation by sending signals to the sending host so as to, for
example: [0082] control the throughput progression [0083] avoid the
overflow of the buffers in the mapper [0084] reduce latency due to
buffering. [0085] explicit request to change congestion control
program These steps can include, but are not limited to, one or
more of the following: [0086] reducing the sending rate of traffic
by altering timestamps, [0087] simulating discard of TCP segments,
[0088] modifying window sizes, [0089] modifying scaling parameters,
and [0090] slowing the transmission of ACKs. The TCP mapper can
also send signals to the sending host to adjust TCP options such as
those documented in Internet Engineering Task Force (IETF) Request
for Comments (RFC) 2780 "IRNA Allocation Guidelines For Values In
the Internet Protocol and Related Headers" by S. Bradner and V.
Paxson, March 2000.
[0091] When a lost packet is re-transmitted, and selective
acknowledgements (SACKs) corresponding to the packets transmitted
after the re-transmitted packet are received by the sending host,
it is highly likely that the re-transmitted packet is also lost. In
another embodiment, the TCP mapper 105 can send signals to the
sending host to repeat the re-transmission.
[0092] In one embodiment, as shown in FIG. 3, there are TCP mappers
105 and 205 at the sending and receiving side of the network 103
respectively. Then, the sending and receiving mappers 105 and 205
can interact with each other to ensure that the constraints for the
various flow types are met. In one embodiment, the receive side TCP
mapper 205 can perform the flow adaptation steps outlined above. In
another embodiment, both the send side and receive side TCP mappers
105 and 205 perform the flow adaptation steps outlined above. In
yet another embodiment, only either the send side TCP mapper 105 or
the receive side TCP mapper 205 performs the flow adaptation steps
outlined above.
[0093] As explained previously certain network performance
measurements, including, but not limited to, for example, packet
jitter and bandwidth, may only be measured at the receive side. In
one embodiment, the sensors in the receive side TCP mapper 205 are
used to measure these parameters. Then, the receive side TCP mapper
205 communicates with the send-side mapper 105 using either in-band
or out of band techniques. Network performance measurements which
could be measured by the receive side TCP mapper 205 include, but
are not limited to, received bandwidth of the associated stream,
total bandwidth being received (sum of all received streams),
packet jitter, bit error rate, packet error rate and inter-packet
spacing. Other useful information which could be useful to tune the
send-side TCP mapper 105 can be exchanged.
[0094] Other information can be exchanged using in-band or out of
band techniques. For example, information on type of subnetworks
found in network 103, for example WiFi, 3G and wired; downstream
network failures; queueing delays and so on, can be
transmitted.
[0095] In one embodiment, the TCP mapper 105 at the sending side
has 2 modes of operation: [0096] "Single-ended"--where there is no
corresponding TCP mapper 205 at the receive side [0097]
"Dual-ended" where there is a corresponding TCP mapper 205 at the
receive side
[0098] In one embodiment, the send side TCP mapper in dual-ended
mode is further configured to summarize one or more TCP
acknowledgements into a single TCP acknowledgement. This is
beneficial in networks where sending multiple acknowledgements
could reduce network performance. In another embodiment, the
receive side TCP mapper is able to take in a single TCP
acknowledgement, derive one or more TCP acknowledgements from the
single TCP acknowledgement, and transmit the one or more derived
TCP acknowledgements from the single TCP acknowledgement. In one
embodiment, both the summarization and derivation are carried out
within one of the TCP congestion control programs.
[0099] FIG. 4 shows another embodiment, whereby sending TCP hosts
201A to 201M are connected to the same mapper 305. In this case,
the mapper 305 aggregates and processes flows from several
different hosts. This could correspond to, for example, an
office.
[0100] FIG. 5 shows yet another embodiment, whereby there are
several sending host-mapper combinations 401A to 401K. Host-mapper
combination 401A contains TCP sending host 401AA and mapper 401AB;
host-mapper combination 401B contains TCP sending host 401BA and
mapper 401BB; and so on until host mapper combination 401K, which
contains TCP sending host 401KA and mapper 401KB. The mappers
401AA-401KA are connected to control network 411 and can interact
with each other. In one embodiment, the mappers 401AA-401KA
interact with each other in a decentralized manner. In another
embodiment, there is centralized control, for example, one of the
mappers 401AA-401KA is considered a master mapper. In another
embodiment, the processor in the master mapper additionally plays
the role of co-ordinating the operation of the other mappers. In
another embodiment, centralized control is provided by a dedicated
system, separate from the TCP mappers. In one embodiment, this
dedicated system could reside within control network 411. In
another embodiment, this dedicated system could be outside of
control network 411.
[0101] Further combinations are also possible. One "hybrid" example
is shown in FIG. 6, where there are several sending-host mapper
combinations 501A, 501B . . . 501K, SOIL. The sending host-mapper
combinations 501A to 501K each contain a TCP sending host and a
mapper. Host-mapper combination 501A contains TCP sending host
501AA and mapper 501AB; host-mapper combination 501B contains TCP
sending host 501BA and mapper 501BB; and so on until host mapper
combination 501K, which contains TCP sending host 501KA and mapper
501KB.
[0102] However, host-mapper combination 501L is a multiple sending
host-single mapper combination, similar to that of FIG. 4. Mapper
501LB is connected to sending hosts 501LA-A to 501LA-M. While only
one multiple sending host-single mapper combination is shown, in
other embodiments there are more than one multiple sending
host-single mapper combinations present.
[0103] The configurations shown in FIGS. 4, 5 and 6 can also be
implemented on the receiving side. Similar to that of FIG. 4, a
single TCP mapper can be connected to several receiving hosts.
Similar to FIG. 5, there may be several receiving host-mapper
combinations. Similar to FIG. 6, there may be several receiving
host-mapper combinations, and one or more of these combinations may
contain multiple receiving hosts. The TCP mappers at the sending
side can then be set to one of the 2 modes previously
described.
[0104] In yet another embodiment, the TCP mappers can also
inter-operate with other TCP control devices within the network.
The control devices and TCP mappers exchange data with each other
and use these as inputs for operations. The control devices may
interact with either send-side or receive-side TCP mappers in
configurations where there is only one or the other; or both
send-side and receive-side TCP mappers in configurations where
there are both.
[0105] In another embodiment, referring to FIG. 2, in the event of
a subnetwork failure within network 103, the TCP mapper 105 will
continue to receive traffic from the sending host 101, and store
traffic within buffers 109A to 109N while looking for an alternate
path within network 103 to send traffic and the individual TCP
congestion control programs within mapper 105 perform tuning for
the alternate path.
[0106] While particular embodiments and applications of the present
invention have been illustrated and described, it is to be
understood that the invention is not limited to the precise
construction and compositions disclosed herein and that various
modifications, changes, and variations may be apparent from the
foregoing descriptions without departing from the spirit and scope
of the invention as defined in the appended claims.
* * * * *
References