- TCP Vegas paper: click here
- TCP Vegas overview: click here
- TCP Vegas uses a more
accurate timer
to compute
RTT
of packets
- In addition to
- timeout and
- duplicate ACKs
TCP Vegas also uses delay as a congestion indication
- TCP Vegas uses a different slow start procedure
|
|
- TCP
Reno
uses a
coarse-grain timer
to measure
RTT
- Reno RTT computation:
- The Reno timer
expires once every 500 msec
- When the timer expires, TCP Reno will compute the RTT for the acknowledged packets and examine which packets need to be retransmitted.
- The Reno timer
expires once every 500 msec
- The paper click here
claims that:
This granularity influence also how often TCP checks to see if it should time out on a segment. Under tests was found that for losses that resulted in a timeout, it took Reno an average of 1100ms from the time it sent a segment that was lost, until it timed out and resent the segment, whereas less that 300ms would have been the correct timeout interval had a more accurate clock been used. Vegas then fixes this problem using a finer coarse-grained timer.
- RTT computation
in TCP Vegas:
- when TCP Vegas transmits a packet,
it reads and stores
the system clock
with that packet ID
- When an ACK is received, TCP Vegas reads the clock again to compute the RTT
Thus, TCP Vegas uses a more accurate timer.
- when TCP Vegas transmits a packet,
it reads and stores
the system clock
with that packet ID
- Because TCP Vegas uses a
more accurate timer,
ot can determine
the packet loss event
from
one duplicate ACK
(Whereas TCP Reno - with a less accurate timer - always waits for THREE duplicate ACKs to conclude if a packet is lost.
Packet loss determination using one duplicate ACK:
- When a duplicate ACK
is received, TCP Vegas checks if:
Now - (Packet Transmission Time) > Timeout for packet Situation: Packet Transmission Recv Dup. ACK time Now ---+------------------------------+---------- <----------------------> Packet Timeout
- If (Now - (Packet Transmission Time) > Timeout for packet), then TCP Vegas will retransmit the packet immediately (and will not wait for 2 more duplicate ACKs to come)
- When a duplicate ACK
is received, TCP Vegas checks if:
- Example:
- Packet 14 is lost
- When packet 14 is received, receiver sends a
duplicate ACK
- When a Vegas sender receives ONE SINGLE duplicate ACK and detects that the time out has expired for the packet, the packet is retransmitted immediately
- Packet 14 is lost
- NOTE:
-
This change is very effective !
Often in congestion, TCP flows will lose a large amount of packets
The loss are often so great that the receiver will send LESS than 3 duplicate ACKs
In other words, the sender will often recover the timeout !!!
- After TCP Vegas
received a duplicate ACK,
TCP Vegas will
monitor
the first 2 new (non-duplicate) ACKS
- Retransmission triggered by new ACK:
- When TCP Vegas receives the
first and
second
new ACK after a
duplicate ACK,
it will check if
any packet timeouts has expired
- TCP Vegas will retransmit any packet whose time out has expired
- When TCP Vegas receives the
first and
second
new ACK after a
duplicate ACK,
it will check if
any packet timeouts has expired
- Example:
Notes:
- Packets 13 and 15 are
lost
(BTW, empirical measurements showed that packet losses often happen in clusters)
- The duplicate ACK
for packet 13
triggers
a retransmission for
packet 13
- Then TCP Vegas receives
a new ACK (ACK 15)
In TCP Reno, this event will never trigger a retransmission
- Because ACK 15 is
the first new ACK after
receiving a duplicate ACK,
TCP Vegas will
check for packet timeouts
Vegas will detect that packet 15 has timed out and retransmits it immediately.
- Packets 13 and 15 are
lost
- NOTE:
- The above checks are made in addition to the tripple duplicate ACK method and a 500 msec timeout clock as used in TCP Reno
- TCP Reno always decrease
CWND when it
detects a packet loss
(through triple duplicate ACK
or timeout)
TCP Vegas will only decrease CWND when a packet is lost during the current transmission rate
- Further elaboration:
Case 1: CWND = CWND /2 (change in transmission rate) | P V --------------+----------------------- \ / ^ \ / | ..... / | | | Detect packet P is lost
Case 2: P (no change in transmission rate) -------------------------------------- \ / ^ \ / | ..... / | | | Detect packet P is lostNotes:
- TCP Vegas will
not decrease
CWND in case 1
when it detects
that packet P was lost
That is because packet P was sent at a different data rate (i.e., prior to the decrease of CWND
- TCP Vegas will
not decrease
CWND in case 1
when it detects
that packet P was lost
- A concrete example:
Notes:
- When TCP Vegas detects packet 13
is lost,
it will
decrease CWND
- because packet 13 was transmitted at the current data rate.
- But when TCP Vegas detects packet 15
is lost,
it will
not decrease CWND
- because packet 15 was transmitted at the previous data rate (i.e., at the data rate before the decrease).
- When TCP Vegas detects packet 13
is lost,
it will
decrease CWND
- TCP Vegas uses
-
- in additional to
time out
and
duplicate ACKs -
the Round Trip Time RTT as (part of) a congestion indication signal.
- Now the use of RTT
as congestion indication is
NOT new
at all.
In fact, Raj Jain was the first to use this technique in 1989 - see his paper: click here
- New congestion signal
used by TCP Vegas:
Number of packets sent in RTT time ------------------------------------- RTT(They included the number of packets sent, is because the number of packets sent will affect the RTT somewhat)
(By the way, this fraction is equal to the average throughput )
- BaseRTT
- The BaseRTT of a TCP connection is the RTT of the connection when it is not congested
Now there is no way to know when a connection is not congested.
So an estimate for the value of BaseRTT is:
BaseRTT = min ( RTT of packets observed )
TCP Vegas can compute the expected throughput that it should get when the network is NOT congested as follows:
CWND Expected Throughput = ------------------ BaseRTT
Next, TCP Vegas calculates the current Actual throughput
This is done as follows:
"Distinguished" ACK for Packet "Distinguished" Packet --------X--------X---X-------X----X------------+----- \ / \ / \ / .............................. |<------------------------------------>| SampleRTT- Select a Distinguished Packet
- Record the
sending time
of this Distinguished Packet
- Tally the number of bytes sent from
the
sending time
of this Distinguished Packet
until the
ACK
for this packet is received.
This is the SampleRTT
- The Actual throughput
is then equal to:
# Bytes sent in SampleRTT Actual Throughput = ----------------------------- SampleRTT
If there is no congestion, the Actual Throughput will be very close to the (optimal) Expected Throughput
The difference between Actual Throughput and Expected Throughput will be greater when there is congestion.
- As mentioned above, the best
throughput that you can expect to get in the connection is
equal to
Expected Throughput
- The Actual Throughput
is the measured throughput and this value
will differ greater from
the best value (= Expected Throughput )
when the network is congested.
- TCP Vegas defines
2 throughput threshold values:
Expected (best possible) Throughput - Actual Throughput: increase CWND CWND unchanged decrease CWND |---------------------+------------------------------+-------------------- 0 α βCongestion decision:
- If
( Expected Throughput - Actual Throughput )
is
less than
α ,
then TCP Vegas will
increase CWND linearly
during the next round of transmission.
- If
( Expected Throughput - Actual Throughput )
is
greater than
β ,
then TCP Vegas will
decrease CWND linearly
during the next round of transmission.
- If ( Expected Throughput - Actual Throughput ) is between α and β , then the congestion window CWND is unchanged during the next round of transmission.
- If
( Expected Throughput - Actual Throughput )
is
less than
α ,
then TCP Vegas will
increase CWND linearly
during the next round of transmission.
- NOTE:
-
TCP Vegas ONLY
uses this congestion control when it
did not detect any packet loss !!!
If there was some retransmission within the SampleRTT period, TCP Vegas will not perform this step (because it would have changed CWND in the mean time !)
- Recall that the slow start procedure in
TCP Reno
will
double
the congestion window CWND
in every
RTT
- In the (last) round of the slow start period -
where packets are lost -
almost half of the packets sent
can be lost !!...
- TCP Vegas tries to avoid
this massive packet loss problem
by using a
"exit slow start" indication signal
(the value of the difference: Actually Throughput - Expected Throughput) to regulate the slow start procedure)
- TCP Vegas' slow start period consists of the following cycles:
increase interval evaluation interval increase interval |--------------------|---------------------|--------------------|..... CWND increases CWND is unchanged CWND increases exponential in this period exponential in this period in this period
evaluation interval: "Distinguished" ACK for Packet "Distinguished" Packet --------X--------X---X-------X----X------------+----- \ / \ / \ / .............................. CWND unchanged * <-- CWND Decision |<------------------------------------>| SampleRTT - During the
evaluation interval,
the
Actual Throughput,
of the connection is measured and
compared against
the
Expected Throughput,
- A threshold
δ
is defined to decide whether
the transmission rate so far is causing
network congestion.
- If:
(Expected Throughput - Actual Throughput) < δ
then TCP Vegas assumes that the exponential increase in window size (and thransmission rate) in the last increase interval DID NOT cause (too much) congestion.
TCP Vegas will then increase the CWND (congestion window) exponentially in the next round of transmission
- However, if:
(Expected Throughput - Actual Throughput) > δ
then TCP Vegas assumes that the exponential increase in window size (and thransmission rate) in the last increase interval STARTED to cause some congestion.
TCP Vegas will then enter the congestion avoidance phase (linear increase and linear decrease - see: click here )