I understand your concern now.
Re: receive rate adjustment: I wouldn't mind helping Sally include these
algorithms in rfc3448bis, although I don't think it's _necessary_ that they go
there. Of FR's two current mechanisms, receive rate adjustment seems safer.
The FR quadrupling may not be ready for inclusion in base TFRC.
So let's brainstorm about mechanisms to maintain the initial rate in the
absence of congestion.
One possibility:
Assume that a Receve Rate option contains a Receive Rate Length. Further
assume that this Receive Rate Length is entirely within the most recent loss
interval's Lossless Length, as reported by Loss Intervals. That is, the
Receive Rate option only covers non-dropped, non-marked packets. Then the
X_recv value, as calculated from the option and the idle period adjustment
currently specified in the draft, may be further adjusted as follows:
(1) X_recv := max(X_recv, initial_rate/2)
Thus, if the receiver sees no congestion, the sender can act as if it was
sending 1/2 the initial rate rather than whatever rate it was actually
sending. This would allow an otherwise unconstrained sender to go immediately
from sending 1 packet per 64 RTTs, to sending the initial_rate.
We could also design a slightly more aggressive mechanism. Here are two more
possibilities:
(2) X_recv := max(X_recv, min(initial_rate, X_recv + initial_rate/2))
(3) X_recv := max(X_recv, initial_rate)
Possibility (2) would allow senders sending 1/2 the initial rate or more, to
go directly to 2*initial_rate in one step. Possibility (3) would allow any
otherwise unconstrained sender to go directly to 2*initial_rate in one step.
(3) might be too aggressive. (1) is simpler, and therefore preferable, but
may not be aggressive enough. Arjuna, what do you think, and what do
simulations say (thanks!)?
Eddie
Arjuna Sathiaseelan wrote:
Dear Eddie,
Thanks for your reply :).
The FIRST feedback packet should not report a particularly low rate
since it
is not over very much time.
Hmmm, I dont think so. Say the sender starts with a initial sending
rate of 4 packets per RTT, I guess when the first packet arrives at
the receiver, the receiver ACKs it. Thus the sending rate could be
less than the minimum sending rate (which should be the initial
sending rate).
The first feedback packet AFTER AN IDLE PERIOD is taken care of by the
Receive
Rate Adjustment algorithm, I would think.
Haa, that means we should include the receive rate adjustment
algorithm in draft-floyd-rfc3448bis-00?
-Arjuna
