a simulation of adaptive packet size in tcp congestion control zohreh jabbari
TRANSCRIPT
A Simulation of Adaptive Packet Size in TCP Congestion Control
Zohreh Jabbari
Traffic management
• routing, congestion control and traffic engineering
Application
Transport
Network
Link
Physical
TrafficManagement
Traffic Management Today
Routers:Routing Protocols
User:Congestion Control
Operator: Traffic Engineering
TCP
• Send a packet & receive an Acknowledgement (ACK).
• Multiple packets. ‘Congestion Window’ (CWND) and ‘Advertised Window’.
TCP 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!
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
Only study the left gateway.– Different Queue Managements. FIFO and RED
Senders Receivers
100 M 100 M
10 M
Pckts drop here!
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 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
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):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.
Question?
TCP ACK generation [RFC 1122, RFC 2581]
Event at Receiver
Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed
Arrival of in-order segment withexpected seq #. One other segment has ACK pending
Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected
Arrival of segment that partially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500msfor 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 thatsegment starts at lower end of gap
TCP RTT
TimeoutInterval = EstimatedRTT + 4*DevRTT
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically, = 0.25)
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
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 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.
• 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
Fast retransmit algorithm:
a duplicate ACK for already ACKed segment
fast retransmit
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 }