Dear Eddie,
Thanks for your prompt thought provoking reply :). Please see inline:
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.
I concur. Because rfc3448-bis provides adequate facility for the
minimum rate to be greater or equal to the initial rate per RTT.
"If (sender has been idle or data-limited)
min_rate = max(2*X_recv, W_init/R);"
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)
I presume you are talking about FR here and not RFC3448-bis. At the
first sight, this looks like a good option to me. This is equivalent
to:
"If (sender has been idle or data-limited)
min_rate = max(2*X_recv, W_init/R);"
which is what I wanted. But then you may end up having 8 packets/RTT
(if initial rate is 4 packets per RTT) using the FR algorithm :). As I
pointed out earlier, this needs to be checked.
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)
Others seem to be very aggressive. I shall do some simulations on
these and would let you know soon.
Ok now coming to an important point, I still need to clarify if the
second receiver adjustment algorithm is still not sufficient to
maintain the initial rate. I did some tests today and I have found out
that it could be due to an implementation problem in ns-2 (not my
source code implementation) rather than a problem with the algorithm.
I am in the process of clarifying this. But the problem for which the
solutions you have described in your mail can be applied if the
"application" is sending one packet every few RTTs. The prescribed
solutions are much better compared to " ignoring a feedback report.
But as I was scrutinizing my code I found an error in the draft! The
error is on how receiver rate length is calculated.
"The Receive Rate Length specifies exactly how many packets were
used to calculate the Receive Rate. It is specified relative to
the feedback packet's Acknowledgement Number. If a feedback
packet's Receive Rate was calculated using data packet sequence
numbers S1...S2, inclusive, where S2 is the feedback packet's
Acknowledgement Number, then Receive Rate Length will be set to
S2 - S1."
Say S1=100, S2=103, ie, the receiver has received 100,101,102,103; so
it uses 4 packets to calculate the recieve rate length. But based on
S2-S1, we get 103-100 = 3!. So I guess this is an error which needs to
be corrected? :)
-Arjuna
--
Dr.Arjuna Sathiaseelan
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3UE
Web: www.erg.abdn.ac.uk/users/arjuna
Phone : +44-1224-272780
Fax : +44-1224-272497
