FAST TCP

Presenter

Farrukh Shahzad

Slides (core) adapted from : IETF presentation slidesLink: http://netlab.caltech.edu/FAST/index.html

Essential strategy : The TCP host sends packets into the network without resource reservation and then the host reacts to observable events.

Originally TCP assumed FIFO queuing at hosts.

Basic idea: each source determines how much capacity is available to a given flow in the network.

ACKs are used to ‘pace’ the transmission of packets such that TCP is “self-clocking”.

CONGESTION CONTROL

3

AIMD (ADDITIVE INCREASE / MULTIPLICATIVE DECREASE)

CongestionWindow (cwnd) is a variable maintained by the TCP source for each connection.

cwnd: is set based on the perceived level of congestion. The Host receives implicit (packet drop) or explicit (packet mark) indications of internal congestion.

MaxWindow = min (CongestionWindow , AdvertisedWindow)EffectiveWindow = MaxWindow – (LastByteSent -LastByteAcked)

4

ADDITIVE INCREASEAdditive Increase is a reaction to perceived available capacity.

Linear Increase basic idea:: For each “cwnd’s worth” of packets sent, increase cwnd by 1 packet (w=w +1)

In practice, cwnd is incremented fractionally for each arriving ACK.

increment = MSS x (MSS /cwnd)cwnd = cwnd + increment

5

MULTIPLICATIVE DECREASE

The key assumption is that a dropped packet and the resultant timeout are due to congestion at a router /switch.

Multiplicate Decrease:: TCP reacts to a timeout by halving

cwnd (w/2).

Although cwnd is defined in bytes, the literature often discusses congestion control in terms of packets (or more formally in MSS == Maximum Segment Size).

cwnd is not allowed below the size of a single packet.

Loss ProbabilityQueuing Delay

Congestion control problem:How to adjust the sending rates of the data sources to make sure that the bandwidth B of the bottleneck link is not exceeded?

B is unknown to the data sources and possibly time-varying

CONGESTION CONTROL

Congestion control problem:How to adjust the sending rates of the data sources to

make sure that the bandwidth B of the bottleneck link is not exceeded?

CONGESTION CONTROL

When åi ri exceeds B the queue fills and data is lost (drops)

=> ) drop (discrete event)

CONGESTION CONTROL

Event-based control:The sources adjust their rates based on the detection of drops

wi (window size) ´ number of packets that can remain unacknowledged for by the destination

CONGESTION CONTROL

wi (window size) ´ number of packets that can remain unacknowledged by the destination

This mechanism is still not sufficient to prevent a collapse of the network if the sources set the wi too large

queuegets full

longerRTT

ratedecreases

queuegets empty

negative feedback

CONGESTION CONTROL

TCP Reno is a good solution for low speed networks but not a viable solution for high-speed networks

Too conservative, not stable, and requires extremely small equilibrium loss

probability

Philosophy of RenoPacket level

Designed and implemented firstFlow level

Understood afterwardsFlow level dynamics determines

Equilibrium: performance, fairness Stability

TCP RENO

- Design flow level equilibrium & stability- Implement flow level goals at packet

level

congestion control algorithm can be designed at two levels.

1- The flow-level (macroscopic) design aims to achieve high utilization, low queuing delay and loss, fairness, and stability.

2- The packet-level design implements these flow level goals within the constraints imposed by end-to-end control

TCP - RENO

Equilibrium problem Packet level: Additive Increase too slow,

Multiplicative decrease too drastic Flow level: required loss probability too small

Dynamic problem Packet level: must oscillate on binary signal Flow level: unstable at large window

TCP RENO

TCP FLOW DYNAMICS- RENO

ACK: W W + 1/W Loss: W W – 0.5W

Packet level

Flow level dynamics

fLossPobablityoPiRTTTi

tptwT

tw iii

i

&

)()(3211 )( 2

ACK: W W + 1/WLoss: W W – 0.5WRENO:

ACK: W W + a(w)/WLoss: W W – b(w)W

ACK: W W + 0.01Loss: W W – 0.125W

High Speed TCP:

Scalable TCP:

TCP VARIANT PERFORMANCE

FLOW LEVEL: RENO, HSTCP, STCP, FAST

Different gain k and utility Ui They determine stability ,

responsiveness and equilibrium.Different congestion measure pi

Loss probability (Reno, HSTCP, STCP) Queueing delay (Vegas, FAST)

Generic flow level dynamics!

)()(1 )( )( ' tU

tpttwi

ii k

windowadjustment

controlgain

flow levelgoal=

Even though Reno, HSTCP, STCP, and FAST look different at the packet level, they have similar equilibrium and dynamic structures at the flow level

FAST TCP is a new TCP congestion avoidance algorithm especially targeted at high-speed, long-distance links, developed at the Netlab, California Institute of Technology and now being commercialized by Fastsoft. It is compatible with existing TCP algorithms, requiring modification only to the computer from which is sending data.

FAST AQM Scalable TCP, where AQM stands for Active Queue Management, and TCP stands for Transmission Control Protocol.

Like TCP Vegas, FAST TCP uses queueing delay along with loss probability as a congestion signal

It seeks to maintain a constant number of packets in queues throughout the network. The number of packets in queues is estimated by measuring the difference between the observed round trip time (RTT with no Queuing) and the base RTT ( Min observed time for connection), If too few packets are queued, the sending rate is increased, while if too many are queued, the rate is decreased

FAST TCP - INTRODUCTION

Data control : Component determines which packets to transmit, (Selects packet from the pool of 3 packets : 1) new packets, 2) packets that lost (negatively acknowledged), and transmitted packets but not ack’d )

Window control : Determines how many packets to transmit, Window control regulates packet transmission at the RTT timescale,

Burstiness control : Determines when to transmit, It smoothes out transmission of packets in a fluid-like manner to track the available bandwidth

FAST - ARCHITECTURE

Burstiness reduction: limits the number of packets that can be sent when an ack advances congestion window by a large amount.

Window pacing: determines how to increase congestion window over the idle time of a connection to the target determined by the window control component. It reduces burstiness with a reasonable amount of scheduling overhead.

FAST – ARCHITECTURE…CONT ..

WINDOWS CONTROL ALGORITHMFAST reacts to both queueing delay and packet loss.

Normal Network ConditionsFAST TCP periodically updates the congestion window based on the average RTT and average queueing delay provided by the estimation component

γ ∈ (0, 1], baseRTT is the minimum RTT observed and α is a positive protocol parameter that determines the total number of packets queued in routers in equilibrium along the flow’s path. The window update period is 20ms.

WINDOWS CONTROL ALGORITHMFAST TCP with FAST Network Flows

cl : A network is assumed as a set of resources with finite capacities, e.g., transmission links, processing units, memory, etc.

di denote the round-trip propagation delay of source i. R be the routing matrix where Rli = 1 if source i uses link l, and 0 otherwise. pl(t) denote the queueing delay at link l at time t. qi(t) = Σl . Rli . pl(t) be the roundtrip queueing delay, in vector notation, q(t) = RT p(t).

Then the round trip time of source i is Ti(t) := di + qi(t).

SELF CLOCKING

A key difference of FAST TCP from those in the literature is that it assumes that a source’s send rate, defined as xi(t) := wi(t)/Ti(t), cannot exceed the throughput it receives. This is justified because of self-clocking: within one round-trip time after a congestion window is increased, packet transmission will be clocked at the same rate as the throughput the flow receives

A consequence of this assumption is that the link queueing delay vector, p(t), is determined implicitly by the instantaneous window size in a static manner:

Click icon to add picture

Click icon to add picture Click icon to add pictureDYNAMIC SHARING: 3 FLOWSFAST RENOx

HSTCP STCP

throughput flows

QUEUING DELAY COMPARISON

OVERALL COMPARISON

THANKS