TCP Flow Control
l Uses
a form of sliding window
l Differs
from mechanism used in LLC, HDLC, X.25, and others:
l Decouples
acknowledgement of received data units from granting permission to send more
l TCP’s
flow control is known as a credit allocation scheme:
l Each
transmitted octet is considered to have a sequence number
TCP Header Fields for
Flow Control
l Sequence
number (SN) of first octet in data segment
l Acknowledgement
number (AN)
l Window
(W)
l Acknowledgement
contains AN = i, W = j:
l Octets
through SN = i - 1 acknowledged
l Permission
is granted to send W = j more octets,
i.e., octets i
through i + j - 1
TCP Credit Allocation
Mechanism
Credit Allocation is
Flexible
Suppose last message B issued was AN = i, W = j
lTo increase
credit to k (k > j) when no new data, B issues AN = i, W = k
lTo
acknowledge segment containing m octets (m < j), B issues AN = i + m, W = j
– m
Flow Control
Perspectives
l Receiver
needs a policy for how much credit to give sender
l Conservative
approach: grant credit up to limit of available buffer space
l May
limit throughput in long-delay situations
l 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)
l After
TCP source begins transmitting, it takes D seconds for first octet to arrive,
and D seconds for acknowledgement to return
l TCP
source could transmit at most 2RD bits, or RD/4 octets
Normalized Throughput
S
1
W > RD / 4
S =
4W/RD W < RD / 4
Window Scale
Parameter
Complicating Factors
l Multiple
TCP connections are multiplexed over same network interface, reducing R and
efficiency
l For
multi-hop connections, D is the sum of delays across each network plus delays
at each router
l If
source data rate R exceeds data rate on one of the hops, that hop will be a
bottleneck
l Lost
segments are retransmitted, reducing throughput. Impact depends on retransmission
policy
Retransmission
Strategy
lTCP relies
exclusively on positive acknowledgements and retransmission on acknowledgement
timeout
lThere is no
explicit negative acknowledgement
lRetransmission
required when:
lSegment arrives damaged, as
indicated by checksum error, causing receiver to discard segment
lSegment fails to arrive
Timers
lA timer is associated with
each segment as it is sent
lIf timer expires before
segment acknowledged, sender must retransmit
lKey Design Issue:
value of retransmission timer
lToo small: many unnecessary
retransmissions, wasting network bandwidth
lToo large: delay in handling
lost segment
Two Strategies
lTimer should
be longer than round-trip delay (send segment, receive ack)
lDelay is
variable
Strategies:
lFixed timer
lAdaptive
Problems with
Adaptive Scheme
lPeer TCP
entity may accumulate acknowledgements and not acknowledge immediately
lFor
retransmitted segments, can’t tell whether acknowledgement is response to
original transmission or retransmission
lNetwork
conditions may change suddenly
Adaptive
Retransmission Timer
lAverage
Round-Trip Time (ARTT)
K
+ 1
ARTT(K + 1) =
1 ∑ RTT(i)
K + 1 i = 1
= K
ART(K) + 1 RTT(K + 1)
K + 1 K + 1
Smoothed Round-Trip Time (SRTT)
SRTT(K + 1) = α × SRTT(K)
+ (1 – α) × SRTT(K + 1)
The older the observation, the less it is counted in the
average.
RFC 793
Retransmission Timeout
RTO(K + 1) =
Min(UB,
Max(LB, β × SRTT(K + 1)))
UB, LB: prechosen fixed upper and lower bounds
0.8 < α < 0.9 1.3 < β < 2.0
lSend
lDeliver
lAccept
In-order
In-window
lRetransmit
First-only
Batch
individual
lAcknowledge
immediate
cumulative
No comments:
Post a Comment