TCP Traffic Control

Introduction
To achieve the good performance for end system, the design and implementation of transport protocol takes the major part It provides the interface between applications and the network facility to get desired QoS Connection-oriented transport protocols like TCP, divide the total flow of application of data into disjoint logical streams

Introduction
It is must to allocate the resources differently among the streams Transport protocols also create rules for transmission and retransmission

Introduction

TCP Flow Control TCP Congestion Control Performance of TCP over ATM

TCP Flow Control

Uses a form of sliding window Differs from mechanism used in LLC, HDLC, X.25, and others: Decouples acknowledgement of received data units from granting permission to send more TCPs flow control is known as a credit allocation scheme Each transmitted octet must have a sequence number

TCP Header Fields for Flow Control

Each transmitted segment includes three fields related to flow control in header 1. Sequence number (SN) of first octet in data segment 2. Acknowledgement number (AN) 3. Window (W) Acknowledgement contains AN = i, W = j: Octets through SN = i - 1 acknowledged Permission is granted to send W = j more octets, i.e., octets i through i + j - 1

Credit Allocation
Assume 200 octets of data are sent. A is grated an initial credit allocation of 1400 octet beginning with octet number 1001 After sending 600 octets in 3 segments, A has shrunk its window size to 800(1601 to 2400) Following the receipt of these segments, B acknowledges for all octets through 1600 and issues a credit of 1000 octets Now A can send octets through 1601 to 2600(5 seg)

Credit Allocation is Flexible

Suppose last message B issued was AN = i, W = j To increase credit to k (k > j) when no new data, B issues AN = i, W = k To acknowledge segment containing m octets (m < j), B issues AN = i + m, W = j - m

Figure 12.2 Flow Control Perspectives

Credit Policy
Receiver needs a policy for how much credit to be given to sender Conservative approach: Grant credit up to limit of available buffer space May limit throughput in long-delay situations Optimistic approach: Grant credit based on expectation of freeing space before data arrives

Effect of Window Size

W = TCP window size (octets) R = Data rate (bps) at TCP source D = Propagation delay (seconds) After TCP source begins transmitting, it takes D seconds for first octet to arrive, and D seconds for acknowledgement to return TCP source could transmit at most RD/4 octets

Normalized Throughput S

1 S =

if

W > RD / 4 W < RD / 4

4W/RD if

Figure 12.3 Window Scale Parameter

Complicating Factors
1. Multiple TCP connections are multiplexed over same network interface, reducing R and efficiency 2. For multi-hop connections, D is the sum of delays across each network plus delays at each router 3. If source data rate R exceeds data rate on one of the hops, that hop will be a bottleneck 4. Lost segments are retransmitted, reducing throughput. Impact depends on retransmission policy

Retransmission Strategy
TCP relies exclusively on positive ACK and retransmission on ACK timeout There is no explicit negative ACK Retransmission required when: 1. Segment arrives damaged, as indicated by checksum error, causing receiver to discard segment 2. Segment fails to Arrive To cope up with this situation there must be a timer.

Timers
A timer is associated with each segment as it is sent If timer expires before segment acknowledged, sender must retransmit Key Design Issue: Value of Retransmission Timer Too small: Many unnecessary retransmissions, wasting network bandwidth Too large: Delay in handling lost segment

Two Strategies
Timer should be longer than Round-Trip Delay (send segment, receive ack) Delay is variable

Strategies: 1. Fixed timer 2. Adaptive

Problems with Fixed Scheme

It is based on the internet behavior It is not always constant and it will get change on network conditions If the value is set too high, the service is always gets slow. If it is set too low positive feedback condition can be develop, leads to more retransmission which increases congestion

Problems with Adaptive Scheme

TCP entity may collect acknowledgements and not allow immediately since of cumulative ack For retransmitted segments, sender cannot know whether the acknowledgement is response to original transmission or retransmission Network conditions may change suddenly

Conclusion
There will be always some uncertainty concerning the selection of best value for the retransmission timer

Adaptive Retransmission Timer

All TCP implementations estimate the current Round-Trip Time delay by observing the pattern of delay for recent segments The timer value is set somewhat greater than the estimated round-trip delay One approach is to take the average of observed round-trip over a number of segments If the average accurately predicts future round trip delays the resulting retransmission timer yields good performances

Adaptive Retransmission Timer

Average Round-Trip Time (ARTT)
K+1

ARTT(K + 1) =

1
K+1 =
i=1

RTT(i)

K ARTT(K) + 1 RTT(K + 1) K+1 K+1

RTT(i) Round-trip time observed for the ith transmitted segments ARTT(K) Average Round Trip Time for first K seg

Drawbacks ARTT
Each term is given equal weight, each is multiplied with the constant 1/(k+1) We have to give greater weights to more recent instants since they will reflect future behavior The method for predicting the next value on the basis of time series of past values is introduced to solve this is called exponential averaging

Exponential Averaging
Smoothed Round-Trip Time (SRTT) SRTT(K + 1) = SRTT(K) + (1 ) RTT(K + 1) takes the value of 0< <1 The expansion of previous equation
SRTT(K + 1) = (1 ) RTT(K + 1)+ (1- )RTT(K)+ 2(1- )RTT(K-1)+.. SRTT(K+1)=0.2 RTT(K+1)+0.16 RTT(K)+0.128 RTT(K-1) Where =0.8

Figure 12.4 Exponential Smoothing Coefficients

Figure 12.5 Exponential Averaging

RFC 793 Retransmission Timeout

RTO(K + 1) = Min(UB, Max(LB, SRTT(K + 1)))

UB, LB: pre-chosen fixed upper and lower bounds Example values for , : 0.8 < < 0.9 1.3 < < 2.0

Implementation Policy Options

Send Policy Deliver Policy Accept Policy In-order and In-window Retransmit Policy First-only, Batch and individual Acknowledge Policy Immediate and cumulative

Send Policy
If the transmissions are infrequent and large there is a low overhead in terms of segment generation and processing If the transmission are frequent and small, the system must provide quick response Danger is Silly Window Syndrome

Silly Window
Caused by poorly-implemented flow control. If a Receiver with this problem is unable to process all incoming data, it requests that its sender reduce the amount of data they send at a time (the window setting on a packet).

Silly Window
If the server continues to be unable to process all incoming data, the window size becomes smaller and smaller, sometimes to the point that the data transmitted is smaller than the packet header, making data transmission extremely inefficient. The name of this problem is due to the window size shrinking to a "silly" value.

Deliver Policy
If the deliveries are infrequent and large , the user is not receiving the data on time as may be desirable If the deliveries frequent and small, there is the unnecessary processing both in TCP,in user software and in operating system system

Accept Policy
When all data segments arrive in order over a TCP connection, TCP places the data in the receiver buffer for the delivery to the user It is also possible in out of order In-Order: Accept only segments that arrive in order, any segment that arrive out-order is discarded In-Window: Accept all segments that are within the receive window.

Retransmit Policy
TCP maintains a queue of segments which are sent but not yet acknowledged. First Only: Maintain one retransmission timer for the entire queue. If ACK is received, remove the particular segment from the queue and reset the timer If the timer expires, retransmit the segment at the front of queue and reset the timer

Retransmit Policy
Batch Maintain one retransmission timer for the entire queue. If ACK is received, remove the particular segment from the queue and reset the timer If the timer expires, retransmit all the segments in the queue and reset the timer

Retransmit Policy
Individual Maintain one retransmission timer for the entire queue. If ACK is received, remove the particular segment from the queue and destroy the corresponding timer If the timer expires, retransmit corresponding segment individually and reset its timer

Acknowledge Policy
When data segment arrives in sequence, the receiving TCP entity has two options concerning the timing of ACK Immediate: When the data is accepted, immediately transmit an empty segment(no data) containing the ack number Cumulative: When the data are accepted, record the need for ack, but wait for outbound segment with data on which to piggyback the ack. To avoid long delay set a window timer

TCP Congestion Control

In Packet switched network or Frame relay, dynamic routing can alleviate congestion by spreading load more evenly Above method are effective only for unbalanced loads and brief rush in traffic But Congestion can only be controlled by limiting total amount of data entering network

TCP/IP Congestion Control is Difficult

1. IP is connectionless and stateless, with no provision for detecting or controlling congestion 2. TCP only provides end-to-end flow control, so we can only handle the congestion control in the intermediate nodes by indirect methods. 3. No supportive, distributed algorithm to bind together various TCP entities 4. Only tool in TCP congestion control is sliding-window flow and error control mechanism

TCP Flow and Congestion Control

The rate at which a TCP entity can transmit is determined by rate of incoming ACKs to previous segments with new credit But in TCP, rate of ACK arrival is determined by the bottleneck in the Round-Trip path between source and destination Bottleneck may be destination or internet The internet bottleneck can be due to congestion

Flow determined by network Congestion

Flow determined by network Congestion(1)

The configuration is abstracted as a pipe connecting source and destination Thickness of the pipe is proportional to the data rate. Source and destination are high capacity networks and operate with high capacity The thinner central portion represents a lower-speed link that creates the bottleneck

Flow determined by network Congestion(2)

Each segment is represented by rectangle whose area is proportional to the number of bits. When a segment is squeezed(press) into the narrow tube, it spreads out in time Pb Minimum segment spacing on the slowest link Pr Segment spacing at the receiver which is equal to Pb

Flow determined by network Congestion

During the acknowledgement, the segment arrival spacing time Ar is equal to Pr Also Ab=Ar This way TCP automatically senses the network bottleneck and regulates its flow accordingly, which is referred as TCPs Self-Clocking

 Here the slowest link in the network is relatively wide about half the data rate of the source The pipe at the destination is narrow Here the ACK can be emitted at a rate equal to the absorption capacity Here the source has no knowledge of pacing (speeding) rate of the internet (congestion) or the status of the destination(flow control)

If the ACK arrive relatively slowly due to network congestion, it is advisable for the source to transmit more slowly than ACK pace The bottleneck along a round-trip path between source and destination can occur in variety of places and be either physical or logical

TCP Congestion Control Techniques

1. 2. 3. 4. 5. 6. 7.

RTT Variance Estimation Exponential RTO Backoff Karns Algorithm Slow Start Dynamic Window Sizing on Congestion Fast Transmit Fast Recovery

Retransmission Timer Management

Three Techniques to calculate retransmission time (RTO) 1. RTT Variance Estimation 2. Exponential RTO Backoff 3. Karns Algorithm

RTT (Round Trip Time) Variance Estimation (Jacobson s Algorithm)

3 sources of high variance(difference) in RTT 1. If data rate is relative low, then transmission delay will be relatively large, with larger variance due to variance in packet size. So SRTT is influenced by the property of data not by the property of network

RTT (Round Trip Time) Variance Estimation (Jacobson s Algorithm)

2. Internet traffic load and conditions may change abruptly due to traffic from other sources causing abrupt changes in RTT 3. TCP entity may not acknowledge each segments immediately because of its own processing delays and its practice of cumulative acknowledgments.

Jacobson s Algorithm
SRTT(K + 1) = (1 g) SRTT(K) + g RTT(K + 1) SERR(K + 1) = RTT(K + 1) SRTT(K) SDEV(K + 1) = (1 h) SDEV(K) + h |SERR(K + 1)| RTO(K + 1) = SRTT(K + 1) + f SDEV(K + 1) g = 0.125 h = 0.25 f = 2 or f = 4 (most current implementations use f = 4)

Figure 12.8 Jacobson s RTO Calculations

Two Other Factors

Jacobsons algorithm can significantly improve TCP performance, but: What RTO to use for retransmitted segments? ANSWER: exponential RTO backoff algorithm Which round-trip samples to use as input to Jacobsons algorithm? ANSWER: Karns algorithm

Exponential RTO Backoff

Increase RTO value each time the same segment is retransmitted backoff process Multiply RTO by constant: RTO = q RTO q = 2 is called binary exponential backoff

Which Round-trip Samples?

If an ACK received is for retransmitted segment, there are 2 possibilities: 1. ACK is for first transmission 2. ACK is for second transmission TCP source cannot distinguish 2 cases No valid way to calculate RTT: From first transmission to ACK, or From second transmission to ACK?

Karn s Algorithm
Do not use measured RTT to update SRTT & SDEV Calculate backoff RTO when a retransmission occurs Use backoff RTO for segments until an ACK arrives for a segment that has not been retransmitted Then use Jacobsons algorithm to calculate RTO

Window Management
Slow start Dynamic window sizing on congestion Fast retransmit Fast recovery Limited transmit

Slow Start
awnd = MIN[ credit, cwnd] where awnd = allowed window in segments cwnd = congestion window in segments credit = amount of unused credit granted in most recent ack cwnd = 1 for a new connection and increased by 1 for each ACK received, up to a maximum

Figure 23.9 Effect of Slow Start

Dynamic Window Sizing on Congestion A lost segment indicates congestion Prudent to reset cwsd = 1 and begin slow start process May not be conservative enough: easy to drive a network into saturation but hard for the net to recover (Jacobson) Instead, use slow start with linear growth in cwnd

Figure 12.10 Slow Start and Congestion Avoidance

Figure 12.11 Illustration of Slow Start and Congestion Avoidance

Fast Retransmit
RTO is generally noticeably longer than actual RTT If a segment is lost, TCP may be slow to retransmit TCP rule: if a segment is received out of order, an ack must be issued immediately for the last in-order segment Fast Retransmit rule: if 4 acks received for same segment, highly likely it was lost, so retransmit immediately, rather than waiting for timeout

Figure 12.12 Fast Retransmit

Fast Recovery
When TCP retransmits a segment using Fast Retransmit, a segment was assumed lost Congestion avoidance measures are appropriate at this point E.g., slow-start/congestion avoidance procedure This may be unnecessarily conservative since multiple acks indicate segments are getting through Fast Recovery: retransmit lost segment, cut cwnd in half, proceed with linear increase of cwnd This avoids initial exponential slow-start

Figure 12.13 Fast Recovery Example

Limited Transmit
If congestion window at sender is small, fast retransmit may not get triggered, e.g., cwnd =3
1. Under what circumstances does sender have small congestion window? 2. Is the problem common? 3. If the problem is common, why not reduce number of duplicate acks needed to trigger retransmit?

Limited Transmit Algorithm

Sender can transmit new segment when 3 conditions are met: 1. Two consecutive duplicate acks are received 2. Destination advertised window allows transmission of segment 3. Amount of outstanding data after sending is less than or equal to cwnd + 2

Performance of TCP over ATM

How best to manage TCP s segment size, window management and congestion control at the same time as ATM s quality of service and traffic control policies TCP may operate end-to-end over one ATM network, or there may be multiple ATM LANs or WANs with non-ATM networks

Figure 12.14 TCP/IP over AAL5/ATM

Performance of TCP over UBR

Buffer capacity at ATM switches is a critical parameter in assessing TCP throughput performance Insufficient buffer capacity results in lost TCP segments and retransmissions

Effect of Switch Buffer Size

Data rate of 141 Mbps End-to-end propagation delay of 6 s IP packet sizes of 512 octets to 9180 TCP window sizes from 8 Kbytes to 64 Kbytes ATM switch buffer size per port from 256 cells to 8000 One-to-one mapping of TCP connections to ATM virtual circuits TCP sources have infinite supply of data ready

Figure 12.15 Performance of TCP over UBR

Observations
If a single cell is dropped, other cells in the same IP datagram are unusable, yet ATM network forwards these useless cells to destination Smaller buffer increase probability of dropped cells Larger segment size increases number of useless cells transmitted if a single cell dropped

Partial Packet and Early Packet discard

Reduce the transmission of useless cells Work on a per-virtual circuit basis Partial Packet Discard
If a cell is dropped, then drop all subsequent cells in that segment (i.e., look for cell with SDU type bit set to one)

Early Packet Discard

When a switch buffer reaches a threshold level, preemptively discard all cells in a segment

Selective Drop
Ideally, N/V cells buffered for each of the V virtual circuits W(i) = N(i) = N(i) V N/V N If N > R and W(i) > Z then drop next new packet on VC i Z is a parameter to be chosen

Figure 12.16 ATM Switch Buffer Layout

Fair Buffer Allocation

More aggressive dropping of packets as congestion increases Drop new packet when: N > R and W(i) > Z B R N-R

TCP over ABR

Good performance of TCP over UBR can be achieved with minor adjustments to switch mechanisms This reduces the incentive to use the more complex and more expensive ABR service Performance and fairness of ABR quite sensitive to some ABR parameter settings Overall, ABR does not provide significant performance over simpler and less expensive UBREPD or UBR-EPD-FBA