Arjuna -
Further to our offline conversations regarding calculating the
receiver rate after long idle periods, where the 3448bis clearly
states that the receiver rate is calculated only for R_m seconds where
R_m is the receiver’s estimate of the RTT, I noticed that this is not
the case in the ns-2 tfrc-sink.cc code (ns-2.29).
In the est_thput () function:
if ((rtt_ > 0) && ((now - last_report_sent) >= rtt_)) {
// more than an RTT since the last report
time_for_rcv_rate = (now - last_report_sent);
if (rcvd_since_last_report > 0) {
thput = rcvd_since_last_report/time_for_rcv_rate;
cout << time_for_rcv_rate<<endl;
}
}
Here the time_for_rcv_rate considers the entire idle period rather
than 1 RTT.
This concurs with why the inflation factor in the receive rate length
came into enforce for FR for TFRC. The DCCP CCID 3 code in ns-2 is
also based on this, hence the receiver is reporting a receive rate
calculated over the entire duration of the idle period.
This has to be corrected?
Yep. Many thanks for the report.
One problem is that I just realized (or was reminded) Thursday,
from talking with Eddie, that TFRC (RFC 3448) and CCID 3 (RFC 4342)
have different specifications for this, though it is not explicitly
stated as different in RFC 4342:
RFC 3448: the receive rate is reported over the last estimated RTT.
RFC 4342: the receive rate is reported over the time since the last
feedback report.
These two specifications for the receive rate differ in two cases:
Case 1: an idle period. (No feedback packet was sent when the
feedback packet last expired.)
Case 2: the receive detects a new loss event. (Feedback is sent
before the feedback timer expired.)
For Case 1, after an idle period, I think it is better for the
feedback packet to report the receive rate over the last RTT, rather
than over the entire idle period. It would certainly be easy to
add a variable to ns-2 to allow either variant to be used, the TFRC
one, or the CCID 3 one. From talking with Eddie, he doesn't
necessarily agree with me that the RFC 3448 definition is better
than the RFC 4342 definition in this case.
At any rate, for rfc3448bis neither of these two definitions provides
a fix for the underlying problem with feedback packets after an
idle period, because unlike rfc3448, rfc3448bis allows initial
sending rates, and sending rates after an idle period, larger than
one packet per RTT. This follows the larger initial windows from
RFC 3390, and their incorporation into CCID 3. So with either
definition of the receive rate, the first feedback packet after an
idle period has to be ignored, because it is reporting a receive
rate of at most 1 packet per RTT, after receiving the first packet
after the idle period, when the sender might be starting up after
the idle period sending four packets per RTT. So we still need the
"ignore the first feedback packet after an idle period", or equivalent,
in rfc3448bis.
For Case 2, of a feedback packet after a loss event is detected,
it has been less than an RTT since the last feedback packet is sent.
The problem with the RFC 3448 language, in this case, is that it
would be inefficient for the receiver to have to compute the receive
rate over the last RTT - in this case, it is much easier for the
receiver to compute the receive rate over the period since the last
feedback packet was sent. For ns-2, the receive keeps the receive
time of recent packets, so it can compute either the RFC3448
definition or the RFC4342 definition of the receive rate. I think
that the RFC3448 definition is better, in this case, in terms of
performance, but the RFC4342 definition is computationally more
efficient. In either case, this needs a little more attention, so
I will look at it. The code for this in ns-2 needs to be fixed in
any case.
Many thanks,
- Sally
http://www.icir.org/floyd/
