Quoting Sally Floyd:
| > (2) One needs to ensure that the TFRC minimum rates are not under-run
| > by doing
| > oscillation prevention (which is possible with integer arithmetic
| > when
| > sqrt(R_sample) > R_sqmean): something like
| >
| > X_inst = X * R_sqmean / sqrt(R_sample)
| >
| > /* where X is obtained as in step (4) of section 4.3 */
| >
| > If (p > 0)
| > X_inst = max(X_inst, s/t_mbi)
| > Else if (not first feedback packet, or the first feedback
| > packet
| > after a nofeedback timer) {
| > X_inst = max(X_inst, s/R)
| > }
|
| I added a slightly revised version of this. You can look at the revised
| version, along with the revised version of Section 4.3, and see what you
| think.
The changes look good, thank you. But I noticed that the entire algorithm in section
4.3 has changed: the first feedback / first feedback packet after nofeedback timer
expiry are no longer ignored; the Limited Receive Rate flag is completely new;
and there are references to the Faster-Restart Receive Rate Length.
With the many interpretations of computing the sending rate (RFC 3448, rfc3448bis,
RFC 4342 + errata, Faster-Restart draft), and the frequent changes to this algorithm,
it looks currently not a good idea to try and implement this: the changes are too
frequent and the interpretations of the same subject are too many and not necessarily
conform. I think it would be good if the IETF people could reach consensus on this,
and agree on a uniform presentation of how to compute/update the sending rate. Otherwise
these divergences will very clearly continue to hinder implementability.
