Thank you for the note, only had time for a quick read through,
three small issues.
1. Related open issue: To deal with idle periods and the like,
in Section 4.7 say that t_i := max(t_i, t_now - RTT/2), to
limit bursts to RTT/2 packets? Has anyone implemented this?
Email from Eddie Kohler and Ian McDonald.
I have implemented this and have come up with an upper bound
of using less than one t_ipi as a threshold. I can provide
a detailed derivation for this but I don't want to post my
patches here - this is from an yet unsubmitted patch set (to be
submitted soon). The experience of using this for over one month
affirms that using (less than) t_ipi as uppper bound cures the
problem of disproportionally large bursts after longer idle times
or when application is sending at a low (constant) bit rate.
2. One minor thing where a clarification would be very helpful:
-> In section 4.6 "Preventing Oscillations"
-> Here it says "The sender obtains the base allowed transmit rate,
X, from the throughput function."
-> But this is confusing, since the result of the throughput function
is X_calc. Since the sender only gets a new R_sample when it gets
feedback, is it meant that the sender obtains the allowed sending
rate X as described in step (4) of section 4.3?
3. Minor Nit in section 8 (formatting)
T_loss = T_before + (T_after - T_before)
* Dist(S_loss,S_before)/Dist(S_after, S_before)
Many thanks,
Gerrit
Quoting Sally Floyd:
| I have submitted the revised version of draft-ietf-dccp-rfc3448bis-01,
| available from
| "http://www.icir.org/floyd/papers/draft-ietf-dccp-rfc3448bis-01.txt";,
| and the list of changes and some known open issues is appended
| below.
|
| If people could look at the changes and check them, that would be
| great.
|
| It would also be good to have feedback on the open issues:
| limitations by X_recv after a loss event; using DCCP's
| Receive Rate Length instead of ignoring one feedback packet?;
| mechanism for limiting the burst size? Is there consensus
| on any of these, that I have missed? Or other issues
| that I have missed?
|
| Many thanks,
|
| - Sally
| http://www.icir.org/floyd/
|
|
| Changes from draft-ietf-dccp-rfc3448bis-00.txt:
|
| * When initializing the loss history after the first
| data packet sent is lost or ECN-marked, TFRC uses
| a minimum receive rate of 0.5 packets per second.
|
| * For initializing the estimated packet drop rate
| for the first loss interval when coming out of slow-start,
| it is ok to use the maximum receive rate so far, not just
| the receive rate in the last round-trip time.
| Feedback from Ladan Gharai.
|
| * General feedback from Gorry Fairhurst:
| - Added a reference for TFRC-SP.
| - Clarified that R_m is sender's estimate of RTT, as reported
| in Section 3.2.1.
| - Added a definition of terms.
| - Added a discussion of why the initial value of the nofeedback
| timer is two seconds, instead of three seconds for the
| recommended initial value for TCP's retransmit timer.
|
| * General feedback from Arjuna Sathiaseelan:
| - Added more details about sending multiple feedback
| packets per RTT.
| - Added change to Section 4.3 to use the first feedback
| packet, or the first feedback packet after a
| nofeedback timer during slow-start, *if min_rate > X*.
|
| * General feedback from Gerrit Renker:
| - Changed "delta" to "t_delta".
| - Changed X_calc to X_Bps, clarified X.
| - Clarified send times in Section 4.7.
| - Changed so that tld can be initialized to either 0 or -1.
| - Fixed Section 5.5 to say that the most recent lost
| interval has weight 1/(0.75*n) *when there have been
| at least eight loss intervals*.
| - Clarified introduction about fixed-size and variable-size
| packets.
|
| * Added more about sender-based variants.
| Feedback from Guillaume Jourjon.
|
| * Corrected that the loss interval I_0 includes all transmitted
| packets, including lost and marked packets (as defined in Section
| 5.3 in the general definition.) Email from Eddie Kohler and
| Gerrit Renker.
|
| * Open issue: Feedback from Ian about problems being limited by
| X_recv after a loss event. There might not be an easy answer.
|
| * Related open issue: Add Faster Restart to RFC3448bis? Or not?
| From Ian McDonald.
|
| * Open issue: Adopt something like DCCP's Receive Rate Length,
| instead of ignoring one feedback packet? From Eddie Kohler.
|
| * Open issue: Add possible mechanisms for limited the maximum
| burst size? Using a token bucket size based on the
| current rate? Or not? Email from Eddie Kohler and Gerrit
| Renker.
|
| * Related open issue: To deal with idle periods and the like,
| in Section 4.7 say that t_i := max(t_i, t_now - RTT/2), to
| limit bursts to RTT/2 packets? Has anyone implemented this?
| Email from Eddie Kohler and Ian McDonald.
|
| * Not done: I didn't add a minimum value for the nofeedback
| timer. (Why would a nofeedback timer need to be bigger
| than max(4*R, 2*s/X)? Email discussing pros and cons from
| Arjuna.
|
| * Not addressed yet: Email thread on "RFC 3448, 4.4: Modifying
| X_recv if p = 0 at the time of last feedback".
|
| * Todo: Update Section 9 on "Changes from RFC 3448" with
| changes since draft-floyd-rfc3448bis-00.txt.
|
|
|
