Module 16 TCP Flow Control and TCP Congestion Control

1
Module 16TCP Flow Control and TCP Congestion
Control
2

• Textbook sections
• BF Section 12.6 Flow Control
• LG Section 7.8.1 Open-loop Control
• LG Section 7.8.2 Closed-loop Control
• Topics
• TCP Flow Control
• Overview
• The small-packet problem
• TCP Congestion Control
• Open-loop Control
• Closed-loop Control

3
1. TCP Flow Control - Overview

• TCP provides a means for the receiver to govern
  the amount of data sent by the sender.
• This is achieved by returning a window with
  every ACK indicating a range of acceptable
  sequence numbers beyond the last segment
  successfully received. The window indicates an
  allowed number of bytes that the sender may
  transmit before receiving further permission.

4
1. TCP Flow Control - The small-packet problem

• The small-packet problem
• There is a special problem associated with small
  packets. For example, when TCP is used for the
  transmission of single-character messages
  originating at a keyboard, the typical result is
  that 41 byte packets (one byte of data, 40 bytes
  of header) are transmitted for each byte of
  useful data. This 4000 overhead is annoying but
  tolerable on lightly loaded networks. On heavily
  loaded networks, however, the congestion
  resulting from this overhead can result in lost
  datagrams and retransmissions, as well as
  excessive propagation time caused by congestion
  in switching nodes and gateways. In practice,
  throughput may drop so low that TCP connection
  are aborted.

5
1. TCP Flow Control - The small-packet problem

• The solution to the small-packet problem
• The solution is to inhibit the sending of new TCP
  segments when new outgoing data arrives from the
  user if any previously transmitted data on the
  connection remains unacknowledged.. This
  inhibition is to be unconditional no timers,
  tests fro size of data received, or other
  conditions are required.. Implementation
  typically requires one or two lines inside a TCP
  program..

6
1. TCP Flow Control - The small-packet problem

• Silly window syndrome/remedies
• Syndrome created by the sender
• Situation Application program on the sender side
  is too slow
• Problem Sender may create many small segments
• Remedy
• Nagles algorithm
• The sending TCP sends the first piece of data it
  receives from the sending application program
  even if it is only one byte
• After sending the first segment, the sending TCP
  accumulates data in the output buffer and waits
  until either the receiving TCP sends an
  acknowledgement or until enough data has
  accumulated to fill a maximum-size segment. At
  this time, the sending TCP can send the segment
• The above step is repeated for the rest of the
  transmission.

7
1. TCP Flow Control - The small-packet problem

• Syndrome created by the receiver
• Situation Application program on the receiver
  side is too slow (receive window becomes very
  small)
• Problem Sender may create many small segments
• Remedy
• Clarks solution
• Acknowledge as soon as the data arrives, but to
  announce a window size of zero until either there
  is enough space to accommodate a segment of
  maximum size or until half of the buffer is
  empty.
• Delayed acknowledgement
• When a segment arrives, it is not acknowledged
  immediately. The receiver waits until there is a
  decent amount of space in its incoming buffer
  before acknowledging the arrived segments
• Advantage reduced traffic
• Disadvantage retransmit the unacknowledged
  segments.

8
LG Figure 8.19 TCP end-to-end flow control
Transmitter
Receiver
Send Window
Receive Window
SlastWa-1
RlastWR1
Rlast
...
...
...
Rnext
Rnew
Octets transmitted and ACKed
Slast
Srecent
SlastWs-1
Slast oldest unacknowledged octet Srecent
highest-numbered transmitted octet SlastWa-1
highest-numbered octet that can be
transmitted SlastWs-1 highest-numbered octet
that can be accepted from the application
Rlast highest-numbered octet not yet read by the
application Rnext next expected octet Rnew
highest numbered octet received correctly RlastWR
-1 highest-numbered octet that can be
accommodated in receive buffer
9
2. TCP Congestion Control

• Open-loop control
• Admission control
• Policing
• Leaky bucket algorithm
• Traffic shaping
• Leaky bucket traffic shaper
• Token bucket traffic shaper
• Closed-loop control
• TCP congestion control

10
2. TCP Congestion Control Open-loop Control
LG Figure 7.53 A leaky bucket
Note The bucket depth is used to absorb the
irregularities in the flow. Deep bucket for
bursty flow. Shallow bucket for smooth flow.
Water poured
irregularly
Once the bucket is full, any additional water
entering it spills over the sides and is lost
Leaky bucket
Water drains at
a constant rate
11
LG Figure 7.54 Leaky bucket algorithm used for
policing
Arrival of a packet at time ta
X X - (ta - LCT)
Yes
X lt 0?
No
X 0
Yes
Nonconforming
X gt L?
packet
No
X X I
X value of the leaky bucket counter
LCT ta
X auxiliary variable
conforming packet
LCT last conformance time
12
2. TCP Congestion Control Open-loop Control
Assumptions 1.Packets are assumed to be of fixed
length (I) 2. The leaky bucket will drain at a
continuous rate of 1 unit per packet time
13
2. TCP Congestion Control Open-loop Control
LG Figure 7.55 Behavior of leaky bucket
Nonconforming
Packet
arrival
Time
LI
Bucket
content
I
Time









14
2. TCP Congestion Control Open-loop Control
Given I 4, L 6, and the arrival times of
packets, values in the following table were
generated using the leaky bucket algorithm.
15
2. TCP Congestion Control Open-loop Control
LG Figure 7.58 Possible traffic patterns at the
average rate of 10 kbps
10 Kbps
(a)
Time
0
1
2
3
50 Kbps
(b)
Time
0
1
2
3
100 Kbps
(c)
Time
0
1
2
3
16
2. TCP Congestion Control Open-loop Control
LG Figure 7.59 A leaky bucket traffic shaper
Shaped
Incoming
Size N
traffic
traffic
Server
Packet
17
2. TCP Congestion Control Open-loop Control
LG Figure 7.60 Token bucket traffic shaper
Tokens arrive
periodically
Size K
Token
Shaped
Incoming
Size N
traffic
traffic
Server
Packet
18
2. TCP Congestion Control - Closed-loop Control

• TCP congestion control
• TCP would start a connection with the sender
  injecting multiple segments into the network, up
  to the window size advertised by the receiver.
  While this is OK when the two hosts are on the
  same LAN, if there are routers and slower links
  between the sender and the receiver, problem can
  arise. Some intermediate router must queue the
  packets, and it is possible for that router to
  run out of space.

19
2. TCP Congestion Control - Closed-loop Control

• Definitions
• Receiver window (rwnd)
• The most recently advertised receive window
• Receive-side limit
• Congestion window (cwnd)
• A TCP state variable that limits the amount of
  data a TCP can send. At any given time, a TCP
  must not send data with a sequence number higher
  than the sum of the highest acknowledged sequence
  number and the minimum of receive window and
  congestion window
• The congestion window is a sender-side limit on
  the amount of data the sender can transmit into
  the network before receiving an ACK
• Initial window (IW)
• The initial window is the size of the senders
  congestion window after the three-way handshake
  is completed
• Slow start threshold (Congestion threshold)
• The value of the congestion window where slow
  start phase stops and congestion avoidance phase
  starts. The initial value is 65,535 bytes
• Segment
• Any TCP/IP data or acknowledgement packet (or
  both)

20
2. TCP Congestion Control - Closed-loop Control
LG Figure 7.63 Dynamics of TCP congestion window
Congestion occurs
Congestion
20
avoidance
15
Congestion
window
Threshold
10
Slow
start
5
0
Round-trip times
21
2. TCP Congestion Control - Closed-loop Control

• Slow start phase
• Algorithm
• Initialization for a given connection sets
  congestion window to one segment and slow start
  threshold to 65,535 bytes
• The sender starts by transmitting one segment and
  waiting for its ACK. When that ACK is received,
  the congestion window is incremented from one to
  two, and two segments can be sent. When each of
  those two segments is acknowledged, the
  congestion window is increased to four. This
  provides an exponential growth.
• The TCP output routine never sends more than the
  minimum of congestion and the advertised receive
  window.
• Slow start phase stops when congestion window
  reaches the slow start threshold. At this point,
  a congestion threshold phase takes over.

22
2. TCP Congestion Control - Closed-loop Control

• Slow start phase
• Flow control
• The advertised receiver window is flow control
  imposed by the receiver.
• The advertised receiver window is related to the
  amount of available buffer space at the receiver
  for a connection
• The congestion window is flow control imposed by
  the sender
• The congestion window is based on the sender's
  assessment of perceived network congestion

23
2. TCP Congestion Control - Closed-loop Control

• Congestion avoidance phase
• This phase assume that the pipe is running close
  to full utilization
• Increase the congestion window by one segment for
  each round-trip time.
• The congestion window stops increasing when TCP
  detects that the network is congested
• When congestion is detected, the slow start
  threshold is first set to one-half of the current
  window size (the minimum of the congestion window
  and the advertised window, but at least two
  segments). Next the congestion window is set to
  one maximum-sized segment.
• Restart phase
• With updated slow start threshold and congestion
  window, the system restarts, using the slow stat
  algorithm.

24
2. TCP Congestion Control - Closed-loop Control

• Congestion detection
• Time-out
• TCP assumes that congestion occurs in a network
  when an acknowledgement does not arrive before
  the time-out expires because of segment loss
• Duplicate ACK
• A TCP receiver SHOULD send an immediate duplicate
  ACK when an out-of-order segment arrives. The
  purpose of this ACK is to inform the sender that
  a segment was received out-of-order and which
  sequence number is expected.
• From the senders perspective, duplicate ACKs can
  be caused by a number of network problems
• They can be caused by dropped segments. In this
  case, all segments after the dropped segment will
  trigger duplicate ACKS.
• They can be caused by the re-ordering of data
  segments by the network (not a rare event along
  some network paths)
• They can be caused by replication of ACK or data
  segment by the network.