OpenAFS Master Repository branch, master, updated. BP--openafs-stable-1_6_x-1307-ga80a88e

Gerrit Code Review
Tue, 21 Jun 2011 18:53:59 -0700 (PDT)

The following commit has been merged in the master branch:
commit a80a88e8ba7ac5e2afc5188add482f4e5323128e
Author: Simon Wilkinson <>
Date:   Sat Jun 18 10:46:53 2011 +0100

    rx: Change the way that the RTT timer is applied
    RX maintains a retryTime for every packet that it has transmitted,
    which is held as the time that that packet was sent, plus the smoothed
    RTT of the connection. If a packet is in the queue with a retryTime
    older than the current time, then it is resent at the first opportunity.
    In some circumstances, this first opportunity will be as a result of
    the resend event timer expiring, in others it will happen as part of
    a normal queue run.
    There are a number of problems with this approach on congested networks.
    Firstly, on a network with a large window size, which is in "normal"
    flow, it means that we will never actually perform fast retransmit as
    the timeout for this packet will have expired before we have received
    any further ACKs. This is because, on a network with a relatively stable
    RTT the ACK for packet n+1, n+2, or n+3 cannot arrive before the
    expected time of arrival of the ACK for packet n. As we retry
    immediately this expected time of arrival has passed, we never have the
    opportunity of using these later ACKs to learn that packet n is lost.
    Secondly, the fact that we may resend packets from a "normal" queue run,
    rather than as a result of a resend event, means that there is no clear
    entry point for resends. As resends should be assumed to be a result of
    network congestion, and result in both the call throttling back, and the
    RTT being increased, this lack of a clean entry point makes things
    As a solution, this patch changes the way in which retransmit times are
    applied to use the algorithm described in RFC2988.
    *) Whenever we send a new packet, we start a timer for the current call
       rto value if one isn't already running.
    *) Whenever we receive an ACK that acknowledges new data, and we have
       packets that are sent but not yet acknowledged, we restart the
       retransmit timer using the current rto value.
    This alogrithm solves the first problem, as it means that if the
    connection is still flowing, we will continue to receive ACKs, and we
    can enter fast retransmit.
    In implementation terms, we longer track a retryTime per packet, and
    instead simply record if a packet has been sent or not. Packets which
    have been sent may only be resent as a result of a resend timer
    expiring, or of entering fast retransmit, so solving the second issue.
    Change-Id: Ic1e2b32876197f8a1fb620b7d70c0c3ec3f6bb88
    Reviewed-by: Derrick Brashear <>
    Reviewed-by: Jeffrey Altman <>
    Tested-by: Jeffrey Altman <>
    Tested-by: BuildBot <>

 src/rx/rx.c        |  301 ++++++++++++++++++++++++++++++----------------------
 src/rx/rx.h        |    3 -
 src/rx/rx_packet.c |   28 ++---
 src/rx/rx_packet.h |    4 +-
 4 files changed, 187 insertions(+), 149 deletions(-)

OpenAFS Master Repository