0%

论文总结:TCP Vegas: New Techniques for Congestion Detection and Avoidance

Lawrence S. Brakmo, Sean W. O’Malley, and Larry L. Peterson. 1994. TCP Vegas: new techniques for congestion detection and avoidance. SIGCOMM Comput. Commun. Rev. 24, 4 (Oct. 1994), 24–35. https://doi.org/10.1145/190809.190317

Introduction

  • Vegas does not involve any changes to the TCP specification; It is merely an alternative implementation that is able to interoperate with any other valid implementation of TCP.
  • Main Results: Vegas can achieve between 40% and 70% better throughput than Reno. And It is achieved by a more efficient use of the available bandwidth. Our experiments show that Vegas retransmits between one-half and one-fifth as much data as does Reno.

Tools

All of the protocols were developed and tested under the University of Arizona;s x-kernel framework.

Simulator

x-kernel-based simulator

  • provides a realistic setting for evaluating protocols, each protocol is modeled by an actual C code
  • available for analysis in the simulator
  • trivial to move protocols between the simulator and the real world

One of the most protocols available in the simulator is called TRAFFIC— it implements TCP Internet traffic based on tcplib.

Trace Facility

Every TCP trace graph have certain features in common.

  1. Hash marks on the x-axis indicate that an ACK was received at that time.
  2. Hash marks at the top of the graph indicate that a segment was sent at that time.
  3. The numbers on the top of the graph indicate the time when the nthn^{th} kilobyte was sent.
  4. Diamonds on top of the graph indicate when a coarse-grained timer event happens to check if there is any timeouts happening.
  5. Circles on top of the graph indicate the time when a coarse-grained timeout occurred, causing a segment to be retransmitted.
  6. Solid vertical lines running the shole height of the graph indicate the time when a segment that is eventually retransmitted was originally sent.

Techniques

five techniques that Vegas employs to increase throughput and decrease losses

the first two is simple extensions that result in a more timely decision to retransmit a dropped segment

the third is an adjustment to TCP’s congestion window resizing algorithm

the fourth is designed to better space transmissioins

the fifth give TCP the ability to anticipate congestion, and adjust its transmission rate accordingly(most novel d

  • More Accurate RTT Calculation
  • New Mechanism for Deciding to Retransmit
  • Modified Window Sizing on Congestion
  • Spike Suppression
  • Congestion Detection and Avoidance

More Accurate RTT Calculation

In Reno, RTT and variance estimates is are computed using a coarse-grained timer(around 500ms). It influences calculation accuracy of RTT and how often TCP checks if it should retransmit a segment.

Vega records the system time when a segment is sent, and records another system time when ACK arrives. It leads to more accurate timeout calculation, and it is used in conjunction with the mechanism described in next subsection.

New Mechanism for Deciding to Retransmit

Vegas extends the duplicate ACK mechanism as follows:

  • Duplicate ACK received: Checks to see if the gap is greater than timeout value. If it is, then Vegas retransmits the segment without having to wait for n(3) duplicate ACKS.
  • Non-duplicate ACK received: If it is the first or second one after a retransmission, Vegas again checks to see if the time interval since the segment was sent is larger than the timeout value. If it is, then Vegas retransmits the segment.

Modified Window Sizing on Congestion

Vegas only decreases the congestion window if the retransmitted segment was previously sent after the last decrease.

Spike Suppression

There are two main reasons that spikes occur:

  • Large cumulative ACKs: a single ACK that acknowledges several kilobytes due to segments arriving out -of-order at the recevier.
  • ACK compression: a sequence of ACKs arrive close together than they were sent.

Ideally, one would want to space the bytes as evenly as possible to prevent overrunning the buffers on the intermediate nodes of the connection.

SegSpacing=RTTMaxSegment/windowSizeSegSpacing = RTT * MaxSegment/windowSize

Congestion Detection and Avoidance

Reno has no mechanism to detect the incipient stages of congestion.