Improving the Performance of TCP Vegas and TCP SACK: Investigations and Solutions

1
Improving the Performance of TCP Vegas and TCP
SACKInvestigations and Solutions

• By
• Krishnan Nair Srijith
• Supervisor A/P Dr. A.L. Ananda
• School of Computing
• National University of Singapore

2
Outline

• Research Objectives
• Motivation
• Background Study
• Transmission Control Protocol (TCP)
• TCP SACK
• Section 1- TCP variants over satellite links

3
Outline (Cont.)

• Section 2 - Solving issues of TCP Vegas (TCP
  Vegas-A)
• Section 3 - Improving TCP SACKs performance
• Conclusion

4
Research Objectives

• Study performance of TCP over satellite links.
• Study TCP Vegas and suggest mechanisms to
  overcome limitations.
• Study TCP SACK and suggest mechanisms to overcome
  limitations.

5
Motivation

• TCP is the most widely used transport control
  protocol.
• TCP SACK was proposed to solve issues with New
  Reno when multiple packets are lost in a window.
• However under some conditions SACK too perform
  badly.
• Overcoming this can enhance SACKs efficiency.

6
Motivation (Cont.)

• TCP Vegas is very different from New Reno, the
  most commonly used variant of TCP.
• Vegas shows greater efficiency, but there are
  several unresolved issues.
• Solving these issues could produce a better
  alternative to New Reno.

7
Transmission Control Protocol

• The most widely used transport protocol, used in
  applications like FTP, Telnet etc.
• It is a connection oriented, reliable, byte
  stream service on top of IP layer.
• Uses 3 way handshake to establish connections.
• Each byte of data is assigned a unique sequence
  number which has to be acknowledged.

8
TCP (Cont.)

• Major control mechanisms of TCP
• Slow Start
• Used to estimate the bandwidth available by a new
  connection
• Congestion Avoidance
• Used to avoid losing packets and if and when
  packets are lost, to deal with the situation

9
TCP SACK

• Was proposed to overcome problems when multiple
  packet are lost by New Reno within a single
  window.
• In SACK, TCP receiver informs the sender of
  packets that are successfully received.
• It thus allows selective retransmission of lost
  packets alone.

10
Section 1

• Studied performance of TCP New Reno and SACK over
  satellite link.
• Paper-
• Effectiveness of TCP SACK, TCP HACK and TCP
  Trunk over Satellite Links - Proceedings of IEEE
  International Conference on Communications (ICC
  2002), Vol.5, pp. 3038 - 3043, New York, April 28
  - May 2, 2002.

11
TCP over Satellite

• There are several factors that limit the
  efficiency of TCP over satellite links.
• Long RTT
• Increase time in slow start mode,decreases
  throughput.
• Large Bandwidth-delay product
• Small window sizes causes under utilization.
• High Bit Error Rates
• TCP assumes congestion and decreases window.

12
Experimental Setup
13
Experimental Setup (Cont.)
14
Results - SACK

• Emulator setup with no corruption
• RTT of 510 ms was introduced by the error/delay
  box to simulate the long latency of the satellite
  link of 10Mbps bandwidth.
• TCP maximum window size was varied from 32 KB
  through 1024KB.
• Files of different size were sent from client to
  server.

15
Results- SACK (Contd.)
Goodput for 1MB and 10MB file transfers for
different window sizes - no corruption
16
Results SACK (Contd.)

• Goodput generally increases with increase in
  window size.
• However for the window size of 1024KB, the
  goodput decreases in both cases, but more in the
  New Reno case.
• This is because, when the window size is set
  larger than the bandwidth-delay product of the
  link (652.8KB), congestion sets in and the
  goodput falls.

17
Results SACK (Contd.)

• Emulator setup with corruption
• Packet errors of 0.5,1.0 and 2 were
  introduced.
• RTT was kept at 510ms.
• Files transfers of size 1MB and 10MB were carried
  out with varying window sizes.

18
Results SACK (Contd.)
Goodput at 1 corruption
Goodput for 10MB file at different corruption
19
Results SACK (Contd.)

• Again, the 10MB file transfer goodput decreases
  when window size is increased beyond 652.8KB
  because of the presence of congestion in addition
  to corruption.
• SACK is able to handle this situation better and
  provides a better goodput.

20
Result - SACK (Contd.)

• Satellite Link

• The goodput increases as window size is
  increased, as long as the window size is kept
  less than the bandwidth-delay product.
• SACK performs better than New Reno for both the
  file sizes as well as for all the window sizes
  used.

Goodput in KBps for 1MB and 10MB file transfers
for varying window size satellite link
21
Summary

• The performance of TCP SACK was compared with
  New Reno in a GEO satellite environment.
• It was shown that SACK performs better than New
  Reno unless the level of corruption is very high.

22
Section 2

• Studied the limitations of TCP Vegas and proposed
  changes to overcome them (TCP Vegas-A).
• Paper-
• TCP Vegas-A Solving the Fairness and Rerouting
  Issues of TCP Vegas - accepted for Proceedings
  of 22nd IEEE International Performance,
  Computing, and Communications Conference (IPCCC)
  2003, Phoenix, Arizona, 9 - 11 April, 2003.

23
TCP Vegas

• Proposed by Brakmo et al. as a different form of
  TCP congestion mechanism.
• It uses a different bandwidth estimation scheme
  based on fine-grained measurement of RTTs.
• The increment of cwnd in TCP Vegas is governed by
  the following algorithm

24
TCP Vegas (Cont.)

• Calculate
• Expected_rate cwnd/base_rtt
• Actual_rate cwnd/rtt
• Diff expected_rate actual rate

cwnd 1, if diff lt a
cwnd 1, if diff gt ß
cwnd
cwnd, otherwise
a1 ß3
25
Issues with TCP Vegas

• Fairness
• Vegas uses a conservative scheme, while New Reno
  is more aggressive.
• New Reno thus attains more bandwidth than Vegas
  when competing against it.
• Furthermore, New Reno aims to fill up the link
  space, which Vegas interprets as sign of
  congestions and reduces cwnd.

26
Issues with Vegas (Cont.)

• Vegas was proposed by Hasegawa et al. to tackle
  this issue.
• However, this method assumes that an increase in
  RTT is always due to presence of competing
  traffic.
• Furthermore, it introduces another parameter
  count(max), whose chosen value is not explained.

27
Issues with TCP Vegas (Cont.)

• Re-routing
• Vegas calculates the expected_rtt using the
  smallest RTT of that connection (baseRTT).
• When routes change during the connection, this
  value can change, but Vegas cannot adapt if this
  new smallest RTT value is more than the original
  one, since it cannot know whether the change is
  due to congestion or route change.

28
Issues with Vegas (Cont.)

• Vegas assumes RTT increase is due to congestion
  and decreases cwnd, just opposite of what it
  should be doing.
• La et al. proposed a modification to Vegas to
  counter this problem, but their solutions adds
  more variables K,N,L,d and ?, whose optimum value
  is still open to debate.

29
Issues with Vegas (Cont.)

• Unfair treatment of old connections
• It has been shown that Vegas is inherently unfair
  towards older connection.
• The critical window size that triggers a
  reduction in cwnd is smaller in older connection
  and larger in newer connection.
• Similarly, critical cwnd that triggers an
  increase in congestion window is lesser for newer
  connections.

30
Vegas-A Solving Vegas Problems

• To solve these issues, a modification to the
  algorithm is proposed, named Vegas-A.
• The main idea is to make the values of the
  parameters a and ß adaptive and not fixed at 1
  and 3.
• The modified algorithm is as follows

31
Vegas-A algorithm

• if ß gt diff gt a
• if Th(t) gt Th(t-rtt) cwnd cwnd 1, a a1,
  ß ß1
• else (i.e if Th(t) lt Th(t-rtt)) no update of
  cwnd, a, ß
• else if diff lt a
• if a gt1 and Th(t) gt Th(t-rtt) cwnd cwnd 1
• else if a gt1 and Th(t) lt Th(t-rtt) cwnd cwnd
  1, a a-1, ß ß-1
• else if a 1 cwnd cwnd1

32
Vegas-A Algorithm (Cont.)

• else if diff gt ß
• cwnd cwnd-1, a a-1, ß ß-1
• else
• no update of cwnd, a, ß

33
Simulation of Vegas vs. Vegas-A

• Simulations used Network Simulator (NS 2)
• Wired and satellite (GEO and LEO) links were
  simulated.
• NS 2 Vegas agent was modified to work as Vegas-A
  agent.

34
Wired link simulation
Simulated wired network topology
35
Wired simulation (Cont.)

• Re-routing condition
• Route change was simulated by changing RTT of
  S1-R1 from 20ms to 200ms after 20s into the
  simulation.
• Bandwidth of S1-R1, R1-R2 and R2-D1 was 1Mbps and
  RTTs of R1-R2 and R2-D1 were 10ms.
• Simulation run for 200 seconds.

36
Re-routing simulation
37
cwnd variation for Vegas and Vegas-A due to RTT
change
38
Throughput variation for Vegas due to RTT change
39
Throughput variation for Vegas-A due to RTT change
40
Bandwidth sharing with New Reno

• S1 uses Vegas/Vegas-A while S2 uses New Reno.
• S1-R1 and S2-R18Mbps, 20ms (RTT)
• R2-D1 and R2-D28Mbps, 20ms (RTT)
• R1-R2 800Kbps, 80ms(RTT)
• S1 started at 0s and S2 at 10s.

41
Throughput of TCP New Reno and Vegas over
congested link
42
Throughput of TCP New Reno and Vegas-A
connections over congested link
43
Competing against New Reno

• When 3 Vegas/Vegas-A connections and New Reno
  were used, Vegas-A was again found to obtain a
  fairer share of the bandwidth compared to Vegas.

44
Old vs. New Vegas/Vegas-A

• 5 Vegas/Vegas-A connections were simulated
  starting at intervals of 50 seconds.

45
Bias against high BW flows

• It has been shown that Vegas is biased against
  connections with higher bandwidth.
• Simulations conducted to check if Vegas-A fares
  better.
• 3 sources S1,S2,S3.
• S1-R1128Kbps, S2-R1256Kbps,
• S3-R1512Kbps, R1-R2 400Kbps

46
High BW flows bias (Cont.)

• The table below shows that Vegas-A does indeed
  perform better than Vegas.

47
Retaining properties of Vegas

• While trying to overcome the problems of Vegas,
  Vegas-A should not lose properties of Vegas.
• One Vegas/Vegas-A connection simulated
• S1-R11Mbps, 45ms RTT
• R1-R2250Kbps, 45ms RTT
• R2-D11Mbps, 10ms RTT

48
Retaining properties of Vegas (Cont.)
Comparison of New Reno, Vegas and Vegas-A
connections over a 100ms RTT link
49
Retaining properties of Vegas(Cont.)

• The effect of changing buffer size on the
  performance of New Reno, Vegas and Vegas-A was
  studied next.
• RTT was set to 40ms and bottleneck link BW was
  set to 500Kbps.

50
Retaining properties of Vegas(Cont.)
Comparison of New Reno, Vegas and Vegas-A
connections with different router buffer queue
size
51
Vegas-A on satellite links

• Geo Satellite links
• Uplink and downlink were 1.5Mbps each.
• Terminals at New York and San Francisco.
• Different PERs were simulated on the link.

52
Vegas-A on GEO Satellite
Performance on a GEO link
53
Vegas-A on GEO satellite
54
Vegas-A on LEO

• Simulated using NS 2
• 780Km altitude, orbital period 6206.9s
• Interstellar separation32.72 degree
• Terminal at Berkeley and Boston

55
Vegas-A on LEO links
56
RTT changes over LEO satellite link
57
(No Transcript)
58
Summary

• Vegas-A was proposed to mitigate problems
  associated with Vegas.
• It was shown that Vegas-A performs better than
  Vegas when competing with New Reno.
• Vegas-A is able to overcome re-routing limitation
  of Vegas.

59
Summary

• Vegas-A does not suffer from unfairness against
  old and high bandwidth connections issues.
• Vegas-A performs better than Vegas in LEO and GEO
  satellite link.
• At the same time, Vegas-A retains all good
  properties of Vegas.

60
Section 3

• Studied the worst case limitation of TCP SACK and
  proposed change in the packet format to overcome
  the problem.
• Paper-
• Worst-case Performance Limitation of TCP SACK
  and a Feasible Solution - Proceedings of 8th
  IEEE International Conference on Communications
  Systems (ICCS), Singapore, 25 - 28 November 2002.

61
Limitation of SACK

• TCP Options field can have a maximum length of 40
  bytes.
• This limits the number of SACK blocks whose
  information the receiver can send, to 4.
• Under certain error scenarios this limitation of
  TCP SACK leads to retransmission of successfully
  received packets.

62
Example
63
Present SACK option format
64
The proposal

• Send 32-bit sequence number for only the right
  edge of the 1st (A)
• Represent each edge as offset from edge A. We
  denote them O12, O21, O22 On1, On2, where O12 is
  the offset of the left edge of first block from
  A, O21 O22 are respectively the right and left
  edges of the second block, and so on.
• Find out the biggest number among these offsets
  (denote it by Omax). Let X be ?log2 (Omax)?
  (where ?x? is the smallest integer larger than
  x).

65
The proposal (Cont.)

• Thus, we can represent all the offsets using 'X'
  bits.
• This number 'X' needs to be sent to the data
  sender within the SACK option fields.
• The sequence numbers range from 0 to 232-1, the
  maximum value that X can take is 32.
• Need 5 bits to send the value of X. To keep it
  simple, we allocate 1 byte for this purpose. This
  is the extra byte that the new format has after
  the Length field, labeled 'X'.

66
The proposal (Cont.)

• The first field after 'X' will be the right edge
  of the 1st block - a 32-bit sequence number.
• The next field (O12) is the offset of the left
  edge of the 1st block with respect to the right
  edge. We represent this number using X bits
  instead of the usual 32 bits.
• All the offsets are computed with respect to the
  right edge of the 1st block, as this is the only
  absolute 32-bit sequence number that will be sent
  to the data sender.

67
The proposal (Cont.)
68
Simulation 1

• The scenario explained earlier was simulated
  using NS and the List error model.

69
Simulation 1 (Cont.)
70
Simulation 2

• The two-state Markov error model of NS was used
  to simulate the second scenario.
• The values of the Markov matrix used are

71
Simulation 2 (Cont.)

• The results above shows the throughput of SACK
  connections, when using the present and the
  proposed implementation.

72
Summary

• Current SACK implementation has the limitation of
  being able to send a maximum of only 3 or 4 SACK
  blocks with each ACK.
• In this paper we proposed an alternate
  representation for the SACK blocks in the option
  field of the TCP segment for TCP SACK
  implementation to overcome this limitation.
• Using examples and simulations, we showed that
  the modified implementation of SACK produces
  better TCP performance in terms of the throughput
  obtained.

73
Conclusions

• Analyzed performance of TCP New Reno and SACK
  over satellite links.
• Studied and suggested mechanisms to overcome
  limitation of TCP Vegas.
• Analyzed performance of Vegas-A and showed that
  it works better than Vegas in wired and satellite
  links.

74
Conclusion (Cont.)

• Studied and proposed mechanism to overcome SACK
  limitation.
• Analyzed the new mechanism and proved that it
  does perform better than SACK.

75
Thank You

• Questions?