U.S. patent application number 10/418298 was filed with the patent office on 2003-12-18 for receiver-based rtt measurement in tcp.
Invention is credited to Berzosa, Fernando, Burmeister, Carsten, Hakenberg, Rolf, Klinner, Thomas.
Application Number | 20030231636 10/418298 |
Document ID | / |
Family ID | 29716778 |
Filed Date | 2003-12-18 |
United States Patent
Application |
20030231636 |
Kind Code |
A1 |
Berzosa, Fernando ; et
al. |
December 18, 2003 |
Receiver-based RTT measurement in TCP
Abstract
A method of performing Round Trip Time (RTT) measurement in a
data packet receiver using a Transmission Control Protocol (TCP)
for communication via a network with a sender, said method
comprising the steps of sending an acknowledgement for a currently
received data packet to the sender, measuring a first time instant
when sending the acknowledgement, triggering at the sender the
transmission of an expected data-packet, measuring a second time
instant when the expected data packet is received, and calculating
the round-trip time based on the measured first and second time
instants.
Inventors: |
Berzosa, Fernando;
(Darmstadt, DE) ; Hakenberg, Rolf; (Darmstadt,
DE) ; Klinner, Thomas; (Aschaffenburg, DE) ;
Burmeister, Carsten; (Hamburg, DE) |
Correspondence
Address: |
STEVENS DAVIS MILLER & MOSHER, LLP
1615 L STREET, NW
SUITE 850
WASHINGTON
DC
20036
US
|
Family ID: |
29716778 |
Appl. No.: |
10/418298 |
Filed: |
April 18, 2003 |
Current U.S.
Class: |
370/395.52 ;
370/252 |
Current CPC
Class: |
H04L 43/0864 20130101;
H04L 43/10 20130101; H04L 43/0888 20130101; H04L 69/16
20130101 |
Class at
Publication: |
370/395.52 ;
370/252 |
International
Class: |
H04L 012/28 |
Foreign Application Data
Date |
Code |
Application Number |
Jun 18, 2002 |
EP |
02013311.2 |
Claims
1. A method of performing Round Trip Time (RTT) measurement in a
data packet receiver using a Transmission Control Protocol (TCP)
for communication via a network with a sender, said method
comprising the following steps: sending an acknowledgement for a
currently received data packet to the sender, measuring a first
time instant when sending the acknowledgement, triggering at the
sender the transmission of an expected data packet, measuring a
second time instant when the expected data packet is received, and
calculating the RTT measurement based on the measured first and
second time instants.
2. The method according to claim 1, wherein the RTT measurement is
only performed when the sender is not in a slow start phase.
3. The method according to claim 1, wherein the RTT measurement is
only performed when a flow control variable signalled from the
receiver to the sender has been constant for a predetermined number
of received data packets.
4. The method according to claim 1, wherein the receiver indicates
an upper limit of the sending rate to the sender.
5. The method according to claim 1, wherein the sending rate is
controlled by an advertised window size serving as flow control
command.
6. The method according to claim 5, wherein the sending bit rate is
controlled by a dynamically varying congestion window.
7. The method according to claims 5 and 6, wherein the sending bit
rate is controlled in accordance with the minimum of the congestion
window and the advertised window as signalled by the receiver.
8. The method according to claim 1, wherein a sequence number of
the expected data packet is calculated on the basis of the sequence
number of the currently acknowledged data packet SN_ack, the
advertised window awnd and the maximum segment size MSS according
to the formula SN.sub.--expect=SN.sub.--ack+(awnd-1)*MSS
9. The method according to claim 4, wherein when the advertised
window awnd has been decreased, the RTT measurement is blocked
until an additional number of (awnd_old-awnd_new) packets are
received.
Description
FIELD OF THE INVENTION
[0001] This invention relates to packet data transmissions, in
particular transmission of data using the Transmission Control
Protocol (TCP) over Internet Protocol (IP) networks. TCP provides
stability of networks by its integrated congestion and flow control
mechanisms. Further, information on TCP and IP networks are, for
instance, available from U.S. Pat. No. 6,298,041 B1.
BACKGROUND ART
[0002] While the TCP sending rate is normally controlled by the
sender, there are scenarios and environments, where the receiver
has some knowledge of the used links and bit rates, which make it
worthwhile to let the receiver control the data transmission rate
of the sender to some extent. In order to apply this mechanism, the
receiver should have knowledge of the Round Trip Time (RTT) value
to control or limit the sender's bit rate. As a result, the sender
would not have to probe for the available bit rate by itself, which
normally comes to the expense of packet losses and is less accurate
than the receiver's information.
[0003] The sending bit rate in the TCP sender is controlled by a
sliding window called congestion window. The sender sends data and
receives cumulative acknowledgements. Outstanding data is the data
that the sender has already sent, but has not received
acknowledgements for it. The sender is allowed to have the amount
of outstanding data equal to the current value of the congestion
window. Because the data is usually acknowledged one RTT after it
was send, the allowed sending bit rate, B_send can be calculated
from the RTT and the congestion window size, cwnd, as:
B_send=cwnd/RTT. An example of these typical values could be
RTT=100 ms and B_send=64 Kbit/s.
[0004] The congestion window at the server is dynamically adjusted
according to gathered network information, e.g. in cases of packet
losses, the TCP sender would assume congestion in the network and
deflate the window. In cases of no packet losses, the window is
slightly and regularly increased. However, the window which TCP
uses to control the sending of data packets, is the minimum of the
congestion window and another window-size signalled by the receiver
called the advertised window, awnd. This is usually used for the
flow control features of TCP, i.e. to ensure that a fast TCP sender
does not send more data than the receiver can consume.
[0005] In conclusion, the receiver can limit the upper sending rate
of the sender of a TCP connection, by using the integrated flow
control and send an advertised window with the value calculated
from RTT and maximum sending bit rate.
[0006] If only one connection member has data to send, RTT
measurements for the receiver in a TCP connection is only possible
at the beginning of a connection (TCP starts with a 3-way
handshake). The measurement, which the receiver can perform at
connection setup, is not accurate, because it is based on small
control packets (usually around 40 bytes). The data packets are
much larger in size, e.g. 1500 bytes, and thus the RTT is usually
much higher than for the small control packets.
[0007] Considering this, receivers can make a rough RTT measurement
at connection set-up, but do not have further RTT information
afterwards. As the RTT is usually dynamic and variable in IP
networks, the receiver should collect RTT information more
frequently to perform a reliable sending bit rate control at the
sender.
[0008] As described above, the receiver in a TCP connection can
control the sending bit rate of the sender by signalling an upper
limit in form of the advertised window. However, in order to
calculate an advertised window to be signalled, the receiver needs
an RTT measurement. The better and more accurate the measurement
is, the better is the window calculation and the better is the link
usage after the sender adopted the window size.
SUMMARY OF THE INVENTION
[0009] The present invention provides a method of performing
round-trip time (RTT) measurements in a data packet receiver in a
fast and reliable manner as set forth in claim 1. Preferred
embodiments of the method are subject to various dependent claims.
According to the method of the present invention, the receiver
determines the time interval between sending of an acknowledgement,
which triggers transmission of a new data packet, and the time
instant of receiving the triggered data packet. If this measurement
mechanism is done an a regular basis, it provides the receiver with
a fairly good estimation of the RTT.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] In the following, the invention will be described in further
detail with reference to the accompanying drawing which show:
[0011] FIG. 1 are flow charts illustrating several example
requirements before starting the RTT measurement.
[0012] FIGS. 2-4 example transmissions of data packets from the
sender to the receiver to illustrate several requirements before
starting the RTT measurement, and
[0013] FIG. 5 a flow chart of the RTT measurement according to the
present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0014] A receiver having a TCP connection with a sender via a
network can start an RTT measurement by sending an acknowledgement
to the sender and waiting for receipt of a data packet triggered by
this acknowledgement. However, the receiver should ensure that
several requirements are fulfill before starting RTT measurement.
In the following, several example requirements are described.
[0015] For the purpose of the following description, a data packet
consists of a header having a typical length of 40 bytes, this
header including a sequence number field which indicates the first
data byte in this segment. This value can serve as an identifier
for the data packet. A typical size for a TCP packet including
header and data is 1500 bytes. Generally, it is understood by those
skilled in the art that an acknowledgement contains the awnd value
and the sequence number of the data packet which the sender of the
acknowledgement is expecting to receive, this is known as the
acknowledgement number.
[0016] In the following FIG. 1A illustrates the general
requirements and FIG. 1B shows an implementation example. For the
corresponding requirements, like numbers followed by the respective
indication A or B have been chosen in order to facilitate the
understanding.
[0017] As a first requirement R1 after start (step 100 in FIG. 1),
the receiver has to ensure that the sender is flow controlled (by
means of the advertised window awnd, see step 200A) and it is no
longer in the TCP slow start phase. During TCP slow start phase,
bursts of data packets occur and therefore the RTT measurement can
be disturbed. A simple and conservative way of ensuring this
requirement is to wait until several data packets are received.
After an amount of 2*awnd-1 packets is sent (see 200B in FIG. 1B),
either the sender's window reaches awnd or the sender has already
reached congestion avoidance phase before that. Note that here and
in the following description, the variable awnd is in units of
segments, whereas in real TCP, the variables awnd and cwnd are in
units of bytes.
[0018] If, for example, a value for awnd is 10 data segments is
considered after receiving 19 packets, it can be assumed that the
sender is no longer in the slow start phase.
[0019] In FIG. 2, this requirement is illustrated in an exemplary
manner. In this case awnd=5 segments, the lines from left to right
represent data packets from the sender to the receiver, the number
in the middle being the sequence number (this is just an example
since in reality SN is given in bytes). The numbers at the right
axis are the values of the SN_ack.
[0020] The Figure shows that waiting 2*awnd-1=2*5-1=9 packets
(until packet with SN=10 arrives) coincides with the point at where
the sender is flow-controlled. This means that every ACK packet
only triggers one data packet at the sender. The first packet in
the example for which this applies is packet number 10.
[0021] A second requirement R2 is that the receiver should be able
to estimate the sequence number of the data packet the current
acknowledgement is going to trigger at the sender. In other words,
that the receiver is able to calculate the value of SN expect (step
300A). This check succeeds if the advertised window awnd has not
been increased for a predetermined number of packets (step 300B). A
side effect of increasing the value of the advertised window is the
possibility of having bursts of packets at the sender. This would
also disturb the RTT measurement and erroneously increase its
value.
[0022] In FIG. 3 the awnd value changes from 5 to 7 and according
to this requirement no RTT measurement can be started for the next
7 packets. The numbers at the right axis represent now the value of
the awnd in number of packets. The reason is that the receiver is
not able to determine the value of SN_expect. The Figure also shows
the burst of packets transmitted by the sender, which might disturb
this measurement due to higher processing times. These effects
would not necessarily last for this number of X=awnd packets but is
a safe limit.
[0023] A further query 400A representing a third requirement R3 is
performed to check whether the ACK triggers a new data packet at
the TCP sender (step 400A). This means that a query is performed
whether the awnd value has been decreased (step 400B). If so, no
RTT measurement is possible for a predetermined number of next data
packets. If there is another decrease, it is decided to wait for
additional number of (awnd_old-awnd_new) packets (step 450B).
[0024] In the example illustrated in FIG. 4 the numbers at the
right axis represent again the value of the awnd. At one point in
time, this value changes from 5 to 3. This means that for 5-3=2
packets no RTT measurement can be started. The Figure shows clearly
the reason since no new TCP packet is triggered due to the smaller
window size until 2 new ACKs are received at the sender. Note that
no RTT measurement can be started with the ACK when the
requirements are not fulfilled. The incoming data packets can be
used, though, for the RTT measurement which was started
previously.
[0025] Only if all above-mentioned requirements R1-R3 are
fulfilled, the receiver starts RTT measurement as indicated in step
500A, B with the current acknowledgement. For making an RTT
measurement, the steps as illustrated in FIG. 5 are conducted.
[0026] In step 510, an acknowledgement of the currently received
data packet is sent from the receiver to the sender. Further, as
illustrated as step 520, the time instant T_ack, at which the
acknowledgement was sent, is stored. In step 530, a sequence number
SN_expect of an expected data packet is determined which indicates
the sequence number of the first byte of the TCP data packet
triggered by the current acknowledgement. The expected sequence
number is calculated as follows:
SN.sub.--expect=SN.sub.--ack+(awnd-1)*MSS
[0027] where SN_ack is the acknowledgement number in the current
acknowledgement and MSS denotes the maximum segment size in
bytes.
[0028] In the receiver, in step 540, the sequence number of all
data packets SN_data that are received after T_ack is compared
according to the condition
SN_data.gtoreq.SN_expect.
[0029] If this condition is not true, the receiver waits for the
next received data packet if the condition is true, the next step
550 is performed wherein the actual time instant T_now is stored.
In the next step 560, a calculation of RTT can be performed as
RTT=T.sub.--now-T.sub.--ack.
[0030] Generally, RTT measurements described in the flowchart of
FIG. 5 can be repeated as often as needed and as long as the
requirements shown in FIG. 1 are fulfilled.
* * * * *