Transport Layer - II

1
Transport Layer - II

• Michalis Faloutsos
• Many slides from Kurose-Ross
• Srikanth Krishnamurthy
• S. Kalyanaraman

2
In this set of slides

• TCP variants
• Router assisted congestion control

3
Current TCP Versions

• TCP specs can be implemented in different ways
• TCP versions
• Tahoe (basic as described)
• Reno
• Las Vegas

4
TCP Reno

• Most popular TCP implementation
• Fast retransmit on 3 duplicate ACKs
• Fast recovery cancel slow start after fast
  retransmission
• Half the congestion window threshold, but start
  with congestion window equal to threshold
• Go to congestion avoidance phase
• Optimistic Rationale
• I hope there was only one packet lost
• Since I sent it, I hope it arrives this time

5
Fast Retransmit

• Coarse grained TCP time-outs sometimes lead to
  long periods wherein a connection goes dead
  waiting for a timer to expire.
• Fast Retransmit -- a heuristic that sometimes
  triggers the retransmission of a packet faster
  than permissible by the regular time-out.
• Every time a data packet arrives at a receiver,
  the receiver ACKs even though the particular
  sequence number has been ACKed.
• Thus, when a packet is received in out of order,
  resend the ACK sent last time -- a duplicate ACK!

6
Duplicate ACKs

• When a duplicate ACK is seen by the sender, it
  infers that the other side must have received a
  packet out of order.
• Delays on different paths could be different --
  thus, the missing packets may be delivered.
• So wait for some number of duplicate ACKs
  before resending data.
• This number is usually 3.

7
Fast Recovery

• When the fast retransmit mechanism signals
  congestion, the sender, instead of returning to
  Slow Start uses a pure AIMD.
• Simply reduces the congestion window by half and
  resumes additive increase.
• Thus, recovery is faster -- this is called Fast
  Recovery.

8
TCP Vegas

• Idea infer problems from RTT delay
• Reduce rate before you have loss
• What is a sign of congestion
• When RTT increases above a threshold
• Sending rate flattens
• Decrease sending rate linearly
• Issues
• Estimate RTT
• Set appropriate threshold

9
Intuition
70
60
50
40
KB
30
20
10
0.5
1.0
1.5
4.0
4.5
6.5
8.0
2.0
2.5
3.0
3.5
5.0
5.5
6.0
7.0
7.5
8.5
Time (seconds)
Congestion Window
Time (seconds)
Average send rate at source
2.0
2.5
3.0
3.5
5.0
5.5
6.0
7.0
7.5
8.5
Driving on Ice
Average Q length in router
10
A Visit to Vegas

• Having routers participate in congestion control
  requires changes to core routers -difficult.
• It is better to do this end-to-end.
• However, we want to still have source based
  control -- now, it would be source-based
  congestion avoidance.
• We need a TCP that watches out for signs of
  congestion --TCP Vegas.

11
Noting RTT variations

• How much does the RTT increase with each packet
  sent ?
• Note that with each additional packet, we are
  adding load.
• One way -- compute for every two round trip
  delays (with an increase in a segment) to see if
  observed RTT gt avg of min and maximum RTT.
• If yes, reduce congestion window.

12
A second possibility

• Every RTT increase congestion window by a packet
  (or segment).
• Compute throughput as number of outstanding bytes
  divided by RTT.
• Also keep the value of the throughput that was
  achieved when only one packet was in transit (at
  the beginning of the connection).
• If the difference between current throughput and
  this above tagged throughput is less than 1/2
  decrease congestion window by 1.

13
TCP Vegas

• Somewhat in line with what we saw in the previous
  examples.
• Source tries to match the available bandwidth
  exactly.
• TCP source maintains what is known as BaseRTT --
  the RTT when the flow is not congested --
  typically the minimum of all RTTs observed.
• It uses this value to determine if or not
  congestion is being experienced.

14
The TCP Vegas Algorithm

• Let BaseRTT be the minimum of all measured RTTs
  (commonly the RTT of the first packet)
• If not overflowing the connection, then
• ExpectedRate CongestionWindow / BaseRTT
• Source calculates current sending rate
  (ActualRate) once per RTT
• Source compares ActualRate with ExpectedRate
• Diff ExpectedRate ActualRate
• if Diff lt ?
• --gtincrease CongestionWindow linearly
• else if Diff gt?
• --gtdecrease CongestionWindow linearly
• else
• --gtleave CongestionWindow unchanged

15
Vegas Behavior

• Green Line -- Expected throughput
• Black Line -- Actual throughput
• Shaded area -- region between a and b thresholds

16
Vegas Parameters

• Parameters
• ? 1 packet
• ? 3 packets
• Even faster retransmit
• keep fine-grained timestamps for each packet
• check for timeout on first duplicate ACK

17
Principles of Congestion Control

• Congestion
• informally too many sources sending too much
  data too fast for network to handle
• different from flow control!
• manifestations
• lost packets (buffer overflow at routers)
• long delays (queueing in router buffers)
• Major research issue

18
Consequences of Congestion

• Large delays throughput vs delay trade-off
• We dont want to operate near capacity
• Finite buffers lost packets
• Resending of packets causes
• More packets for the same goodput
• Wasted bandwidth of the packet that gets dropped

19
Causes/costs of congestion scenario 1

• two senders, two receivers
• one router, infinite buffers
• no retransmission

• large delays when congested
• maximum achievable throughput

20
Causes/costs of congestion scenario 2

• one router, finite buffers
• sender retransmission of lost packet

21
Causes/costs of congestion scenario 2

• Always (goodput)
• If packets are dropped

22
Causes/costs of congestion scenario 3

• Four senders, multihop paths, timeout/retransmit
• Congestion in one link -gt retransmits -gt
  congestion in other links

23
Causes/costs of congestion scenario 3
Another cost of congestion when packet
dropped, any upstream transmission capacity used
for that packet was wasted!
24
Approaches towards congestion control
Two broad approaches towards congestion control

• Network-assisted congestion control
• routers provide feedback to end systems
• single bit indicating congestion (SNA, DECbit,
  TCP/IP ECN, ATM)
• explicit rate sender should send at

• End-end congestion control
• no explicit feedback from network
• congestion inferred from end-system observed
  loss, delay
• approach taken by TCP

25
Router Assisted Congestion Control

• Random Early Detection
• Explicit Congestion Notification
• Note often this is referred to as Active
  Networking ie routers are involved in
  perfomance.
• Active Nets is a much more general idea

26
RED Random Early Detection

• Idea routers start dropping packets before they
  are congested
• Benefits make behavior smoother
• How
• When queue is above a thres-1 drop packets with
  probability p
• Issues
• setting the parameters
• Estimating the queue size

27
Thresholds

• two queue length thresholds
• if AvgLen ? MinThreshold then
• enqueue the packet
• if MinThreshold lt AvgLen lt MaxThreshold
• calculate probability P
• drop arriving packet with probability P
• if MaxThreshold ? AvgLen
• drop arriving packet

28
RED probability P

• Not fixed
• Function of AvgLen and how long since last drop
  (count) keeps track of new packets that have been
  queued while AvgLen has been between the two
  thresholds
• TempP MaxP (AvgLen - MinThreshold)
  /(MaxThreshold - MinThreshold)
• P TempP/(1 - count TempP)
• MaxP is often set to 0.02, meaning that the
  gateway drops 1 out of 50 packets when queue size
  is halfway between MinThreshold and MaxThreshold

29
Comments on RED

• Probability of dropping a particular flow's
  packet(s) is roughly proportional to the share of
  the bandwidth that flow is currently getting
• MaxP is typically set to 0.02, meaning that when
  the average queue size is halfway between the two
  thresholds, the gateway drops roughly one out of
  50 packets.

30
RED Dropping probability
P(drop)
1.0
MaxP
A
vgLen
MinThresh
MaxThresh
31
Selecting Parameters

• if traffic is bursty, then MinThreshold should be
  sufficiently large to allow link utilization to
  be maintained at an acceptably high level
• The difference between two thresholds should be
  larger than the typical increase in the
  calculated average queue length in one RTT
  setting MaxThreshold to twice MinThreshold is
  reasonable for traffic on today's Internet

32
Explicit Congestion Notification

• Dropping packets Warn of congestion
• Idea mark packets to notify congestion
• How
• Congested router marks packet (sets a bit)
• Receiver copies bit in the ACK
• Sender reduces its window
• Benefit proactive without losing packets
• Problem sender can ignore it

33
Current Beliefs

• RED ECN are considered to be good
• RED alone has problems

34
Summary

• principles behind transport layer services
• multiplexing/demultiplexing
• reliable data transfer
• flow control
• congestion control
• instantiation and implementation in the Internet
• UDP
• TCP

35
TCP Flow Control

• receiver explicitly informs sender of
  (dynamically changing) amount of free buffer
  space
• RcvWindow field in TCP segment
• sender keeps the amount of transmitted, unACKed
  data less than most recently received RcvWindow

sender wont overrun receivers buffers
by transmitting too much, too fast
RcvBuffer size or TCP Receive Buffer RcvWindow
amount of spare room in Buffer
receiver buffering
36
TCP latency modeling

• Q How long does it take to receive an object
  from a Web server after sending a request?
• TCP connection establishment
• data transfer delay

• Notation, assumptions
• Assume one link between client and server of rate
  R
• Assume fixed congestion window, W segments
• S MSS (bits)
• O object size (bits)
• no retransmissions (no loss, no corruption)

Two cases to consider WS/R gt RTT S/R ACK for
first segment in window returns before windows
worth of data sent WS/R lt RTT S/R wait for ACK
after sending windows worth of data sent
37
TCP latency Modeling
K O/WS
Case 2 latency 2RTT O/R (K-1)S/R RTT -
WS/R
Case 1 latency 2RTT O/R
Green lag
38
TCP Latency Modeling Slow Start

• Now suppose window grows according to slow start.
  
• Will show that the latency of one object of size
  O is

where P is the number of times TCP stalls at
server
- where Q is the number of times the server
would stall if the object were of infinite
size. - and K is the number of windows that
cover the object.
39
TCP Latency Modeling Slow Start (cont.)
Example O/S 15 segments K 4 windows Q
2 P minK-1,Q 2 Server stalls P2
times.
40
TCP Latency Modeling Slow Start (cont.)
41
TCP Vegas Details

• Value of throughput with no congestion is
  compared to current throughput
• If current difference is small, increase window
  size linearly
• If current difference is large, decrease window
  size linearly
• The change in the Slow Start Mechanism consists
  of doubling the window every other RTT, rather
  than every RTT and of using a boundary in the
  difference between throughputs to exit the Slow
  Start phase, rather than a window size value.

42
Expected and Actual Rates

• The source computes an Expected Rate -- Expected
  Rate CongestionWindow/BaseRTT
• Actual Rate is also computed -- number of bytes
  transmitted during the RTT of a tagged packet.
• Diff Expected Rate - Actual Rate.
• Note that the Diff is always greater than or
  equal to zero (BaseRTT is the lowest !).

43
Vegas Rules

• Define two thresholds a and b.
• If Diff lt a, TCP vegas increases congestion
  window linearly during next RTT.
• If Diff gt b, it decreases the congestion window
  linearly.
• If a lt Diff lt b, TCP vegas leaves the congestion
  window as is.

44
Example TCP Vegas
Actual Throughput
Expected throughput