8/2/2019 TCP Trafic

1/82

TCP Traffic Control

8/2/2019 TCP Trafic

2/82

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

8/2/2019 TCP Trafic

3/82

Introduction

It is must to allocate the resources differently among

the streams

Transport protocols also create rules for transmission

and retransmission

8/2/2019 TCP Trafic

4/82

Introduction

TCP Flow Control

TCP Congestion Control

Performance of TCP over ATM

8/2/2019 TCP Trafic

5/82

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

8/2/2019 TCP Trafic

6/82

TCP Header Fields for Flow Control

Each transmitted segment includes three fieldsrelated 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

8/2/2019 TCP Trafic

7/82

8/2/2019 TCP Trafic

8/82

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)

8/2/2019 TCP Trafic

9/82

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

8/2/2019 TCP Trafic

10/82

Figure 12.2 Flow Control Perspectives

8/2/2019 TCP Trafic

11/82

Credit Policy

Receiver needs a policy for how much credit tobe given to sender

Conservative approach: Grant credit up to limit ofavailable buffer space

May limit throughput in long-delay situations

Optimistic approach: Grant credit based onexpectation of freeing space before data arrives

8/2/2019 TCP Trafic

12/82

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 Dseconds for first octet to arrive, and D secondsfor acknowledgement to return

TCP source could transmit at most RD/4octets

8/2/2019 TCP Trafic

13/82

Normalized Throughput S

1 if W > RD / 4

S =

4W/RD if W < RD / 4

8/2/2019 TCP Trafic

14/82

Figure 12.3 Window Scale Parameter

8/2/2019 TCP Trafic

15/82

Complicating Factors

1. Multiple TCP connections are multiplexed oversame network interface, reducing R and efficiency

2. For multi-hop connections, D is the sum of delays

across each network plus delays at each router3. 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 retransmissionpolicy

8/2/2019 TCP Trafic

16/82

Retransmission Strategy

TCP relies exclusively on positive ACK andretransmission 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

segment2. Segment fails to Arrive

To cope up with this situation there must be a timer.

8/2/2019 TCP Trafic

17/82

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 ofRetransmission Timer

Too small: Many unnecessary retransmissions,

wasting network bandwidth

Too large: Delay in handling lost segment

8/2/2019 TCP Trafic

18/82

Two Strategies

Timer should be longer than Round-Trip

Delay (send segment, receive ack)

Delay is variable

Strategies:

1. Fixed timer2. Adaptive

8/2/2019 TCP Trafic

19/82

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 canbe develop, leads to more retransmission which

increases congestion

8/2/2019 TCP Trafic

20/82

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

8/2/2019 TCP Trafic

21/82

Conclusion

There will be always some uncertainty concerning

the selection of best value for the retransmission

timer

8/2/2019 TCP Trafic

22/82

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

8/2/2019 TCP Trafic

23/82

Adaptive Retransmission Timer

Average Round-Trip Time (ARTT)

K + 1

ARTT(K + 1) = 1 RTT(i)

K + 1 i = 1

= 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

8/2/2019 TCP Trafic

24/82

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

8/2/2019 TCP Trafic

25/82

Exponential Averaging

Smoothed Round-Trip Time (SRTT)

SRTT(K + 1) = SRTT(K) + (1 ) RTT(K + 1)

takes the value of 0<

8/2/2019 TCP Trafic

26/82

Figure 12.4 Exponential

Smoothing Coefficients

8/2/2019 TCP Trafic

27/82

Figure 12.5 Exponential

Averaging

8/2/2019 TCP Trafic

28/82

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

8/2/2019 TCP Trafic

29/82

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

8/2/2019 TCP Trafic

30/82

Send Policy

If the transmissions are infrequent and large there isa low overhead in terms of segment generation andprocessing

If the transmission are frequent and small, thesystem must provide quick response

Danger is Silly Window Syndrome

8/2/2019 TCP Trafic

31/82

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).

8/2/2019 TCP Trafic

32/82

Silly Window

If the server continues to be unable to process allincoming 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.

8/2/2019 TCP Trafic

33/82

Deliver Policy

If the deliveries are infrequent and large , the user isnot receiving the data on time as may be desirable

If the deliveries frequent and small, there is theunnecessary processing both in TCP,in user softwareand in operating system system

8/2/2019 TCP Trafic

34/82

Accept Policy

When all data segments arrive in order over a TCPconnection, TCP places the data in the receiverbuffer for the delivery to the user

It is also possible in out of order

In-Order:Accept only segments that arrive in order, anysegment that arrive out-order is discarded

In-Window:Accept all segments that are within the receivewindow.

8/2/2019 TCP Trafic

35/82

Retransmit Policy

TCP maintains a queue of segments which are sentbut not yet acknowledged.

First Only:

Maintain one retransmission timer for the entirequeue. If ACK is received, remove the particularsegment from the queue and reset the timer

If the timer expires, retransmit the segment at thefront of queue and reset the timer

8/2/2019 TCP Trafic

36/82

Retransmit Policy

BatchMaintain one retransmission timer for the entirequeue. If ACK is received, remove the particularsegment from the queue and reset the timer

If the timer expires, retransmit all the segments inthe queue and reset the timer

8/2/2019 TCP Trafic

37/82

Retransmit Policy

IndividualMaintain one retransmission timer for the entirequeue. If ACK is received, remove the particularsegment from the queue and destroy the

corresponding timerIf the timer expires, retransmit correspondingsegment individually and reset its timer

8/2/2019 TCP Trafic

38/82

Acknowledge Policy

When data segment arrives in sequence, thereceiving TCP entity has two options concerning thetiming of ACK

Immediate:

When the data is accepted, immediately transmit anempty 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

topiggybackthe ack.

To avoid long delay set a window timer

8/2/2019 TCP Trafic

39/82

TCP Congestion Control

In Packet switched network or Frame relay, dynamicrouting can alleviate congestion by spreading load

more evenly

Above method are effective only for unbalancedloads and brief rush in traffic

But Congestion can only be controlled by limiting

total amount of data entering network

8/2/2019 TCP Trafic

40/82

TCP/IP Congestion Control is Difficult

1. IP is connectionless and stateless, with noprovision 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 issliding-w

indow

flow and error control mechanism

8/2/2019 TCP Trafic

41/82

TCP Flow and Congestion Control

The rate at which a TCP entity can transmit isdetermined by rate of incoming ACKs to previous

segments with new credit

But in TCP, rate of ACK arrival is determined by thebottleneck in the Round-Trippath between source

and destination

Bottleneck may be destination or internet The internet bottleneck can be due to congestion

8/2/2019 TCP Trafic

42/82

Flow determined by network Congestion

8/2/2019 TCP Trafic

43/82

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

linkthat creates the bottleneck

8/2/2019 TCP Trafic

44/82

Flow determined by network Congestion(2)

Each segment is represented by rectangle whosearea is proportional to the number of bits.

When a segment is squeezed(press) into the narrow

tube, it spreads out in time PbMinimum segment spacing on the slowest

link

Pr Segment spacing at the receiver which is

equal to Pb

8/2/2019 TCP Trafic

45/82

Flow determined by network Congestion

During the acknowledgement, the segment arrival

spacing time

Ar is equal to Pr

AlsoAb=Ar

This way TCP automatically senses the network

bottleneck and regulates its flow accordingly,which is referred as TCPs Self-Clocking

8/2/2019 TCP Trafic

46/82

8/2/2019 TCP Trafic

47/82

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 ACKcan 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)

8/2/2019 TCP Trafic

48/82

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 betweensource and destination can occur in variety of places

and be either physical or logical

8/2/2019 TCP Trafic

49/82

8/2/2019 TCP Trafic

50/82

TCP Congestion Control Techniques

1. RTT Variance Estimation

2.E

xponentialR

TO Backoff3. Karns Algorithm

4. Slow Start

5. Dynamic Window Sizing on Congestion

6. Fast Transmit7. Fast Recovery

8/2/2019 TCP Trafic

51/82

Retransmission Timer Management

Three Techniques to calculate retransmission time

(RTO)

1. RTT Variance Estimation2. Exponential RTO Backoff

3. Karns Algorithm

8/2/2019 TCP Trafic

52/82

RTT (Round Trip Time) Variance Estimation

(Jacobsons 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 tovariance in packet size. So SRTT is influenced by

the property of data not by the property of network

8/2/2019 TCP Trafic

53/82

RTT (Round Trip Time) Variance Estimation

(Jacobsons 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.

8/2/2019 TCP Trafic

54/82

Jacobsons 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)

8/2/2019 TCP Trafic

55/82

Figure 12.8 Jacobsons

RTO Calculations

8/2/2019 TCP Trafic

56/82

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 toJacobsons algorithm?

ANSWER: Karns algorithm

8/2/2019 TCP Trafic

57/82

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

8/2/2019 TCP Trafic

58/82

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 calculateR

TT: From first transmission to ACK, or

From second transmission to ACK?

8/2/2019 TCP Trafic

59/82

Karns Algorithm

Do not use measured RTT to update SRTT & SDEV

Calculate backoff RTO when a retransmission

occurs

Use backoff RTO for segments until an ACKarrives for a segment that has not been retransmitted

Then use Jacobsons algorithm to calculate RTO

8/2/2019 TCP Trafic

60/82

Window Management

Slow start

Dynamic window sizing on congestion

Fast retransmit Fast recovery

Limited transmit

8/2/2019 TCP Trafic

61/82

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 1for each ACK received, up to a maximum

8/2/2019 TCP Trafic

62/82

Figure 23.9 Effect of Slow

Start

8/2/2019 TCP Trafic

63/82

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 incwnd

8/2/2019 TCP Trafic

64/82

Figure 12.10 Slow Start

and Congestion

Avoidance

8/2/2019 TCP Trafic

65/82

Figure 12.11 Illustration of Slow Start and

Congestion Avoidance

8/2/2019 TCP Trafic

66/82

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 ackmust be issued immediately for the last in-ordersegment

Fast Retransmit rule: if 4 acks received for samesegment, highly likely it was lost, so retransmitimmediately, rather than waiting for timeout

8/2/2019 TCP Trafic

67/82

Figure 12.12 Fast

Retransmit

8/2/2019 TCP Trafic

68/82

Fast Recovery

When TCP retransmits a segment using FastRetransmit, 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 sincemultiple 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

8/2/2019 TCP Trafic

69/82

Figure 12.13 Fast

Recovery Example

8/2/2019 TCP Trafic

70/82

Limited Transmit

If congestion window at sender is small, fastretransmit may not get triggered, e.g., cwnd= 3

1. Under what circumstances does sender havesmall congestion window?

2. Is the problem common?

3. If the problem is common, why not reduce

number of duplicate acks needed to triggerretransmit?

8/2/2019 TCP Trafic

71/82

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

8/2/2019 TCP Trafic

72/82

Performance of TCP over ATM

How best to manage TCPs segment size,

window management and congestion

control at the same time as ATMs quality of

service and traffic control policies

TCP may operate end-to-end over one ATMnetwork, or there may be multiple ATM

LANs or WANs with non-ATM networks

8/2/2019 TCP Trafic

73/82

Figure 12.14 TCP/IP over AAL5/ATM

8/2/2019 TCP Trafic

74/82

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

8/2/2019 TCP Trafic

75/82

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 ATMvirtual circuits

TCP sources have infinite supply of data ready

8/2/2019 TCP Trafic

76/82

Figure 12.15 Performance

of TCP over UBR

8/2/2019 TCP Trafic

77/82

Observations

If a single cell is dropped, other cells in thesame IP datagram are unusable, yet ATMnetwork forwards these useless cells todestination

Smaller buffer increase probability of droppedcells

Larger segment size increases number of

useless cells transmitted if a single celldropped

8/2/2019 TCP Trafic

78/82

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 withSDU type bit set to one)

Early Packet Discard When a switch buffer reaches a threshold level,

preemptively discard all cells in a segment

S l ti D

8/2/2019 TCP Trafic

79/82

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

8/2/2019 TCP Trafic

80/82

Figure 12.16 ATM Switch Buffer Layout

ff ll

8/2/2019 TCP Trafic

81/82

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

8/2/2019 TCP Trafic

82/82

TCP over ABR

Good performance of TCP over UBR can be achievedwith minor adjustments to switch mechanisms

This reduces the incentive to use the more complexand more expensive ABR service

Performance and fairness of ABR quite sensitive tosome ABR parameter settings

Overall, ABR does not provide significantperformance over simpler and less expensive UBR-E

PD or UBR-E

PD-FBA