A Simulation of Adaptive Packet
Size in TCP Congestion Control
Zohreh Jabbari
Traffic management
• routing, congestion control and traffic
engineering
Traffic
Management
Application
Transport
Network
Link
Physical
Traffic Management Today
Operator:
Traffic Engineering
User:
Congestion Control
Routers:
Routing Protocols
TCP
• Send a packet & receive an
Acknowledgement (ACK).
• Multiple packets. ‘Congestion Window’
(CWND) and ‘Advertised Window’.
TCP Congestion Control
• Possible events:
→ No congestion
– On time Acknowledgement.
Open cwnd
– Timeout. → Congestion (lost pkt)
Slow down!
– Multiple out of order ACKs. → Congestion (lost pkt)
Slow down!
TCP Congestion Control
• Congestion control algorithm
– On any timeout,
• set cwnd to half the current window size
(multiplicative decrease).
– On each ack for new data,
• increase cwnd by 1/cwnd (additive increase).
– When sending,
• send the minimum of the receiver’s advertised
window and cwnd.
TCP Congestion Control
• Severe congestion:
– Small cwnd.
– Large RTT.
– Exp backoff
– Starved sources
• TCP doesn’t
work here!
Solution
• A more flexible algorithm:
– Changes packet size.
– Smaller packets when network is congested.
– Larger packets otherwise.
TCP VP Congestion Control
• ‘Severe congestion’:
– Adaptive Packet size
• ‘Less congestion’:
– Large packets
• What is ‘Severe congestion’?
– min_cwnd and max_cwnd
– min_pkt_size and max_pkt_size
The simplified algorithm
• Timeout:
– if (cwnd<min_cwnd & pkt_size>min_pkt_size)
• Pkt_size/= 2; (Multiplicative Decrease)
• Receiving an in-order ACK:
– If (cwnd>max_cwnd & pkt_size<max_pkt_size)
• Increase pkt_size by pkt_size/(cwnd+1) (Additive
Increase)
Working Environment
• Working with Ns (Ns-2 or Network Simulator).
– Algorithm in C++ (added to Ns source code)
– A test network.
– Testing scenarios in TCL
– Simulating the scenarios.
Network Topology
Senders
100 M
Pckts
drop
here!
Receivers
100 M
10 M
Only study the left gateway.
– Different Queue Managements. FIFO and RED
Simulation Scenarios
Scenario Num
TCP senders
TCP VP senders
UDP senders
Queuing Policy
1
100
0
0
FIFO
2
0
100
0
FIFO
3
50
50
0
FIFO
4
50
0
10
FIFO
5
0
50
10
FIFO
6
25
25
10
FIFO
7
100
0
0
RED
8
0
100
0
RED
9
50
50
0
RED
10
50
0
10
RED
11
0
50
10
RED
12
25
25
10
RED
Queue management
• FIFO:
– First in First out.
– Last ones are dropped.
• RED (in byte mode):
– Fair sharing!
– Per flow Queuing.
– Considers the size of the packets (byte mode)
Simulation Analysis1
• 2 scenarios:
– 10 UDP sources, 10 TCP sources and 10
TCPVP sources
– One with FIFO & one with RED
• Sorting the sources:
– by the data transferred by each source.
• Comparing median of TCP and TCPVP
sources over time.
Results
“Number of bytes received” vs. “simulation
time” for medians of TCP and TCPVP
sources in a network with 10 TCP 10 UDP
and 10 TCPVP senders in FIFO
The same plot when the router
is using RED in its byte mode.
Simulation analysis2
•
•
•
•
Time independent results:
Long simulations.
Sort sources by their total data transfer.
Plot the CDF of the results for TCP and
TCP VP.
Results
• (a) TCP and VP comparison in scenario 3 (50 TCP 50
TCPVP, FIFO)
• (b) scenario 9 (50 TCP 50 TCPVP, RED)
Results
• (a) TCP and VP comparison in scenario 6 (25 TCP, 25
TCPVP, 10 UDP, FIFO)
• (b) and scenario 12. (25 TCP, 25 TCPVP, 10 UDP, RED)
Results
• A comparison between scenario 1 and 2 in (a)
• and between 7 and 8 in (b).
• Scenario 1 and 7 are all TCP scenarios, with FIFO and RED
respectively. 2 and 8 are all VP scenarios with FIFO and RED
respectively
Hypothesis
• Why TCP is better?
– 40 bytes of header on
each pckt!
– Decreased throughput
for TCP VP.
Summery
Scenario Description
FIFO
scenario
TCP Sources
VP Sources
UDP Sources
3
50
50
0
9
50
50
0
6
25
25
10
12
25
25
10
1
100
0
0
2
0
100
0
7
100
0
0
8
0
100
0
TCP
RED
VP
TCP
VP
Conclusion
• When using RED in byte mode:
– TCP VP is usually much better than TCP.
• Otherwise:
– Smaller packet sizes get penalized
– Better to use TCP.
Future Work
• Testing the packet header overhead
Hypothesis.
Future Work
• What is happening here?
Future Work
• Tuning the TCP VP parameters.
– min_pkt_size, min_cwnd & max_cwnd
– Minimizing the variance of sent bytes over
sources.
Future Work
• A study of TCP VP and TCP when both
FIFO and RED are present in the network!
References:
•
•
•
•
•
•
•
•
[1] V. Jacobson. Congestion avoidance and control. SIGCOMM Comput.
Commun. Rev. , 18(4):314-329, 1988.
[2] Sally Floyd and Van Jacobson. Random early detection gateways for
congestion avoidance. IEEE/ACM Transactions on Networking, 1(4):397413, 1993.
[3] Frank Hutter, Holger Hoos, and Thomas Stützle. Automatic Algorithm
Configuration based on Local Search. AAAI, 2007.
[4] NS-2 network simulator webpage: http://www.isi.edu/nsnam/ns/.
[5] W. Stevens. TCP Slow Start, Congestion Avoidance, Fast Retransmit,
and Fast Recovery Algorithms, January 1997, RFC2001
[6] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control, April
1999, RFC 2581.
[7] The official Nsnam Wiki:
http://nsnam.isi.edu/nsnam/index.php/Main_Page
[8] R. Jain, K.K. Ramakrishnan, and D. Chiu. Congestion avoidance in
computer networks with a connectionless network layer. Technical Report
DEC-TR-506, Digital Equipment Corporation, 1987.
Question?
TCP ACK generation
[RFC 1122, RFC 2581]
Event at Receiver
TCP Receiver action
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
Delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
Arrival of in-order segment with
expected seq #. One other
segment has ACK pending
Immediately send single cumulative
ACK, ACKing both in-order segments
Arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
Immediately send duplicate ACK,
indicating seq. # of next expected byte
Arrival of segment that
partially or completely fills gap
Immediate send ACK, provided that
segment starts at lower end of gap
TCP RTT
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)
TimeoutInterval = EstimatedRTT + 4*DevRTT
Question:
If TCP frequently timeouts even if it sends
only 1 segment per round, does it imply
anything, and how does TCP handle it?
Exponential back-off
• When?
– Consecutive timeouts, possibly due to severe
congestion
• How? On each timeout
– Retransmit the smallest sequence number not
yet acknowledged
– Double the timer
• End of exponential back-off
– If ACK is received
Question:
What is fast retransmit and how does it
work?
Fast Retransmit
• Time-out period often • If sender receives 3
ACKs for the same
relatively long:
data, it supposes that
– long delay before
resending lost packet
segment after ACKed
data was lost:
• Detect lost segments
– fast retransmit: resend
via duplicate ACKs.
– Sender often sends
many segments backto-back
– If segment is lost,
there will likely be
many duplicate ACKs.
segment before timer
expires
Fast retransmit algorithm:
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}
a duplicate ACK for
already ACKed segment
fast retransmit