Some thoughts on improving the Faster Restart draft
(http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02.
txt) :
1) I have two thoughts about using the receiver rate adjustment algorithms:
* I believe that we may not need the receiver rate adjustment
algorithms for TFRC after idle periods as the receiver rate is calculated
only for 1 RTT and the deflated rate may not be that significant, whereas we
"may" have the receiver rate adjustment algorithms for CCID 3 since the
receiver rate is reported over the time since the last feedback report. I am
not sure why we have these two different behaviors for TFRC and CCID 3!
* I have a feeling that the receiver rate adjustment algorithm may not
be completely needed for both TFRC and CCID 3 since the recent algorithm
ensures that the rate never goes below X_active_min_rate. So do we still
need the adjustment algorithm in place?
2)
X_active_min_rate := min(8*s, max(4*s, 8760 bytes)).
Should be
X_active_min_rate := min(8*s, max(4*s, 8760 bytes))/RTT?
2) Maintaining the X_active_min_rate during data-limited period:
/* First phase. Adjust X_recv so send rate doesn't drop
below X_active_min_rate as the result of an idle and/or
slow period. */
If the feedback packet does not indicate a loss or mark
and the old X_recv >= X_active_min_rate/2, then
X_recv := max(X_recv, X_active_min_rate/2).
I did these modifications in ns-2 and did some tests to find out that this
is too conservative in the presence of both packet loss and data-limited
period and the performance is worse than TFRC (RFC3448-bis).
RFC3448-bis-02c states
If (feedback packet reports Limited Receive Rate
or sender has been data-limited over period
covered by the last feedback packet)
min_rate = max(2*X_recv, W_init/R);
Else // typical behavior
min_rate = 2*X_recv;
So you can see that even though in the presence of packet loss and during a
data-limited period, the min-rate for TFRC would be atleast a min of
W_init/R. This is not the case with FR.
As maintaining the min_rate or X_active_min_rate would be limited by the
throughput equation. I would suggest removing the loss or mark criteria
while considering the X_active_min_rate for idle or during data-limited
period.
/* First phase. Adjust X_recv so send rate doesn't drop
below X_active_min_rate as the result of an idle and/or
slow period. */
If the old X_recv >= X_active_min_rate/2, then
X_recv := max(X_recv, X_active_min_rate/2).
So I basically suggest that even in the presence of loss, we could maintain
the X_recv to atleast the X_active_min_rate as the sending rate would be
then limited to the throughput equation. So it shouldn't be a problem.
Any suggestions?
-Arjuna
-------------------------------
Dr.Arjuna Sathiaseelan
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3UE
Email: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
Web: <http://www.erg.abdn.ac.uk/users/arjuna>
www.erg.abdn.ac.uk/users/arjuna
Phone : +44-1224-272780
Fax : +44-1224-272497
