tcp congestion control and queue management

TCP Congestion Control and Queue Management

Engineering Internet QoS 2

Outline

Congestion Control• Slow start• AIMD• Fast Retransmit/Recovery

Queue Management• ECN• RED• WRED• RIO


Why Study TCP Congestion Control in a QoS Course?

Most Internet services are based on TCP• file transfer, e-mail, world wide web,

telnet all use TCPQuality of these valuable services largely

depends on TCP’s congestion control mechanisms

These services will still be very valuable even in the next generation Internet with many new multimedia services


IPv4 Header Format (Revision)


Source port # Destination port #

31

Application Data (variable length)

Sequence numberAcknowledgement number

Receiver window sizeUrgent pointer dataChecksum

FSRPAUHeaderlength Unused

Options (variable )

0

TCP Segment Format (Revision)


UDP Header (Revision)


Client Server

SYN, SeqNo=88

SYN, ACK, SeqNo=155, AckNo=89

ACK, AckNo=156

3-Way Handshake (Revision)

Reprinted with Permission from “Engineering Internet QoS - Jha & Hassan, Artech House Publishing, Norwood, MA, USA. www.artechhouse.com

http://www.artechhouse.com/




Acknowledged

Waiting for ACK

0 1 2 3 54 6 7 8 9 10 11 12 13

Can be sent

Can't be sent

1 2 3 40 5 6 7 8 9 10 11 12 13

0 1 2 3 54 6 7 8 9 10 11 12 13

0 1 2 3 54 6 7 8 9 10 11 12 13

Step 1

Step 2

Step 3

Step 4Time

Sliding Window (Revision)






TCP Congestion Control

Assumes FCFS or FQ scheduling disciplineAcknowledgements used to regulate

transmission speedFeed is of implicit nature

• no explicit rate notification from network

Each source determines network capacity• Dynamically adapt to capacity changes


Congestion Control Mechanism

Congestion indicated by retransmission timout

Sliding Window mechanism used for Congestion control

Window size is control as follows• Increased upon receipt of ACKs• Decreased upon expiration of

retransmission timer


Slow Start

Initially CongestionWindow = 1 MSS Increase CongestionWindow by 1 upon receipt of ACK

• Allowed window size = min (AdvertisedWindow, CongestionWindow) AdvertisedWindow = Receiver’s available window size

• Window size doubled every RTT See figure on next foil

• Initially 1 segment sent• Upon receipt of 1st ACK, 2 segments are sent• Once ACK for these two segments arrive, four

segments are sent


Slow Start Example






Additive Increase/Multiplicative Decrease

Additive Increase phase• Increase window size by 1/CongestionWindow

for each ACK received Window size increase by 1 every RTT

Transition from Exponential• Variable ssthresh = ½ initial window size• Upon loss, ssthresh set to half the current

window size Rather maximum of the min (Congestion Window,

Adverstised Window)/2 or 2 MSS


AIMD






Fast Retransmit

Timer implementation may be too big• wastage of bandwidth

Fast retransmit adapts to congestion quickly• Duplicate ACKs trigger retransmission• TCP-Reno: 3 duplicate ACKs before

retransmission timer expiration triggers retransmission of segment TCP-Reno also uses fast recovery : No slow

start after fast retransmission


Proactive Congestion Management

TCP-Vegas• Keep track of RTT measurements• Longer RTT indicates future congestion• Rate reduced linearly


Queue Management

Queue management different from packet scheduling• Packet scheduling – which packet to send next

+ per-flow bandwidth Guarantees Queue management tasks:

• Move packets to appropriate queue• Remove packets from a queue on request from

packet scheduler• Drop and remark packets if queue full or

approaching saturation


Explicit Congestion Notification

RFC2481 proposed ECN scheme (based on DECbit)

IPv4 ToS field to indicate • ECN Capable Transport (ECT) bit:

whether end system is ECN capable• Congestion Experienced (CE): Network

elements mark this flag to indicate congestion


Global Synchronization Problem

Drop tail scheme creates global synch. Problem• Congested router drops packet from multiple

flows simultaneously• Each TCP sender detects loss and goes into

slow start• Congestion situation improves at the

bottleneck router• TCP sources start increasing their rate again• If the router can’t cope with this load, source

back off again. RED proposal to eliminate this problem


Random Early Detection (RED)

Drop packets from randomly selected flows with some drop probability whenever the queue length exceeds some threshold• Don’t wait for queue to become full

(proactive).No explicit indication to source

• TCP source use standard implicit timeout mechanism


RED Queue

ttt QlenAvQlenAvQlen 1)1(






RED Details (contd)

Two queue length thresholds• if AvQlent < Minth then buffer the packet;

No congestion

• if AvQlent > Maxth , discard packet (drop probability 1); High congestion

• If Minth <= AvQlent <= Maxth , packet drop based on drop probability p. Drop proability increases linearly towards Maxp as

buffer occupancy approaches Maxth


RED packet drop probability

)/(thth

MinMaxMinAvQlenMaxp thtp Reprinted with Permission from “Engineering Internet QoS - Jha & Hassan, Artech House Publishing, Norwood, MA, USA. www.artechhouse.com





Weighted RED

Set of Minth , Maxth and and Maxp for each class Drop probability is applied from this set based on

packet marking• Packets to be marked with different drop levels

Diffserv chapter to revisit packet marking etc.

• Higher drop priority to be discarded first if queue occupancy increases beyond minimum threshold

Router vendors support up to 8 set of values based on IPv4 precedence level


WRED






RED with In/Out (RIO)

RIO scheme assumes edge router marking of packets conforming to SLA• Conforming packets, in profile• Non-conforming packets, out of profile

Packets out of profile dropped first if a router suffers congestion

Different set of parameters used for in/out of profile packets

tcp congestion control and queue management

Documents