rx: Change the way that the RTT timer is applied

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.

Change-Id: Ic1e2b32876197f8a1fb620b7d70c0c3ec3f6bb88
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>