Title: A Simulation of Adaptive Packet Size in TCP Congestion Control
1A Simulation of Adaptive Packet Size in TCP
Congestion Control
2Traffic management
- routing, congestion control and traffic
engineering
Traffic Management
3Traffic Management Today
Operator Traffic Engineering
Routers Routing Protocols
User Congestion Control
4TCP
- Send a packet receive an Acknowledgement (ACK).
- Multiple packets. Congestion Window (CWND) and
Advertised Window.
5TCP Congestion Control
- Possible events
- On time Acknowledgement.
- Timeout.
- Multiple out of order ACKs.
? No congestion Open cwnd
? Congestion (lost pkt) Slow down!
? Congestion (lost pkt) Slow down!
6TCP 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 receivers advertised
window and cwnd.
7TCP Congestion Control
- Severe congestion
- Small cwnd.
- Large RTT.
- Exp backoff
- Starved sources
- TCP doesnt
- work here!
8Solution
- A more flexible algorithm
- Changes packet size.
- Smaller packets when network is congested.
- Larger packets otherwise.
9TCP 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
10The simplified algorithm
- Timeout
- if (cwndltmin_cwnd pkt_sizegtmin_pkt_size)
- Pkt_size/ 2 (Multiplicative Decrease)
- Receiving an in-order ACK
- If (cwndgtmax_cwnd pkt_sizeltmax_pkt_size)
- Increase pkt_size by pkt_size/(cwnd1) (Additive
Increase)
11Working 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.
12Network Topology
- Only study the left gateway.
- Different Queue Managements. FIFO and RED
Pckts drop here!
Senders
Receivers
100 M
100 M
10 M
13Simulation 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
14Queue 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)
15Simulation 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.
16Results
The same plot when the router is using RED in
its byte mode.
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
17Simulation analysis2
- Time independent results
- Long simulations.
- Sort sources by their total data transfer.
- Plot the CDF of the results for TCP and TCP VP.
18Results
- (a) TCP and VP comparison in scenario 3 (50 TCP
50 TCPVP, FIFO) - (b) scenario 9 (50 TCP 50 TCPVP, RED)
19Results
- (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)
20Results
- 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
21Hypothesis
- Why TCP is better?
- 40 bytes of header on each pckt!
- Decreased throughput for TCP VP.
22Summery
Scenario Description Scenario Description Scenario Description FIFO FIFO RED RED
scenario TCP Sources VP Sources UDP Sources TCP VP TCP VP
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
23Conclusion
- When using RED in byte mode
- TCP VP is usually much better than TCP.
- Otherwise
- Smaller packet sizes get penalized
- Better to use TCP.
24Future Work
- Testing the packet header overhead Hypothesis.
25Future Work
26Future Work
- Tuning the TCP VP parameters.
- min_pkt_size, min_cwnd max_cwnd
- Minimizing the variance of sent bytes over
sources.
27Future Work
- A study of TCP VP and TCP when both FIFO and RED
are present in the network!
28References
- 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)397-413, 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.
29Question?
30TCP ACK generation RFC 1122, RFC 2581
TCP Receiver action Delayed ACK. Wait up to
500ms for next segment. If no next segment, send
ACK Immediately send single cumulative ACK,
ACKing both in-order segments Immediately send
duplicate ACK, indicating seq. of next
expected byte Immediate send ACK, provided
that segment starts at lower end of gap
Event at Receiver Arrival of in-order segment
with expected seq . All data up to expected seq
already ACKed Arrival of in-order segment
with expected seq . One other segment has ACK
pending Arrival of out-of-order
segment higher-than-expect seq. . Gap
detected Arrival of segment that partially or
completely fills gap
31TCP RTT
EstimatedRTT (1- ?)EstimatedRTT ?SampleRTT
DevRTT (1-?)DevRTT
?SampleRTT-EstimatedRTT (typically, ? 0.25)
TimeoutInterval EstimatedRTT 4DevRTT
32- Question
- If TCP frequently timeouts even if it sends only
1 segment per round, does it imply anything, and
how does TCP handle it?
33Exponential 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
34- Question
- What is fast retransmit and how does it work?
35Fast Retransmit
- If sender receives 3 ACKs for the same data, it
supposes that segment after ACKed data was lost - fast retransmit resend segment before timer
expires
- Time-out period often relatively long
- long delay before resending lost packet
- Detect lost segments via duplicate ACKs.
- Sender often sends many segments back-to-back
- If segment is lost, there will likely be many
duplicate ACKs.
36Fast retransmit algorithm
event ACK received, with ACK field value of y
if (y gt 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