OpenAFS Master Repository branch, openafs-stable-1_6_x, updated. openafs-stable-1_6_0pre6-27-ga7716cf

[Gerrit Code Review]

The following commit has been merged in the openafs-stable-1_6_x branch:
commit a7716cf6d253b67e342c6b055497c2076622cd12
Author: Simon Wilkinson <sxw@your-file-system.com>
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
    tricky.
    
    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.
    
    (cherry picked from commit a80a88e8ba7ac5e2afc5188add482f4e5323128e)
    Reviewed-on: http://gerrit.openafs.org/4862
    Reviewed-by: Derrick Brashear <shadow@dementia.org>
    Reviewed-by: Jeffrey Altman <jaltman@openafs.org>
    Tested-by: Jeffrey Altman <jaltman@openafs.org>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    
    Change-Id: I023c9b52b104f8930f8d0dd628612cec2226fee0
    Reviewed-on: http://gerrit.openafs.org/4918
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Derrick Brashear <shadow@dementia.org>

 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