Gorry -
Here are a list of issues we have found from the email discussions we
have been involved with, and/or our research. Please don't take these
as corrections, but they are things that we'd like you to consider
(apologies in advance if these are wrongly attributed to individuals -
these names are for points of contact if you need clarification). I
hope this is helpful,
Many thanks! I think that I have addressed all of these issues in the
revised version of the draft
(that I will submit to the internet-drafts office later tonight.
The slightly more detailed feedback is below.
Again, many thanks!
- Sally
>RFC 3448.bis (TFRC)
>===================
>
>http://www.ietf.org/internet-drafts/draft-ietf-dccp-rfc3448bis-00.txt
>
>--------------------------------------------------
>1) Gorry -
>* The abstract implies usefullness for telephony, whereas TFRC-SP
states
>that it is better suited to such applications (which are often
>data-limited and may have bursts of idleness). This statement seems
>inconsistent.
>* The introduction states:
>" TFRC-SP will be specified in a later document."
>- Please replace by a reference to the RFC.
DONE.
>--------------------------------------------------
>2) Ian - In section 4.3 of RFC3448 we have the equation for X as:
> If (p > 0)
> Calculate X_calc using the TCP throughput equation.
> X = max(min(X_calc, 2*X_recv), s/t_mbi);
>
>I have been doing experiments where I deliberately drop real-time
>packets when I don't believe they will get to the other end before an
>expiry time. What happens though is that I can't then transmit packets
>later on due to the above equation as in practice it becomes
>X=2*X_recv and X_recv quickly goes close to 0 as it is the receive
>rate since last feedback. Feedback gets sent once per RTT I think and
>so if you don't send anything for one RTT you get X=s/t_mbi in effect
>which is 530/64 for my size packets - i.e. a sending rate of 10 bytes
>per second. In practice I don't get quite this bad as I don't drop off
>transmitting that long usually but I still definitely get penalised.
NOTHING DONE.
I don't know of a fix, short of Faster Restart.
>--------------------------------------------------
>3) Gorry - Section 4.2: nofeedback timer initial value?
>"the nofeedback timer is set to expire after 2 seconds"
>
>Why is this 2 seconds?
>
>My first thoughts were that it should be 3secs for consistency with
TCP.
> 2 secs is likely to be OK. But, why should we have different initial
>versions of such timers running around? We're just basically picking
>something we think is reasonable in all such cases, so we might as well
>be uniform about it in TFRC?
ADDED TEXT.
>--------------------------------------------------
>4) Gerrit -
>The discussion on packet-based sending rate computation is lacking
depth
>and substance: the formula on page 1 is not new information, since
>already implied by the throughput equation.
MODIFIED.
>Discussion of `packet-based' versus `byte-based' is missing, perhaps
>this is similar (?) to TCP.
DISCUSSED IN THE NEXT PARAGRAPH ABOUT TFRC-SP.
>The discussion in section 1 suggests that TFRC works for both
fixed-size
>and variable-size packets - I have really doubts here if that is
>intended, as it contradicts a number other publications which say that
>TFRC should use fixed packet size.
MODIFIED.
>--------------------------------------------------
>5) Gerrit - Section 4.1:
>Clarifying discussion on segment size in 4.1 is helpful
>and improves on RFC 3448 (this is a general comment, I do think that
>rfc3448bis is useful, but maybe not yet fully finished).
OK. NOTHING TO DO.
>--------------------------------------------------
>6) Gerrit - Section 5.2:
>I have a suggestion for a simpler formula using two's complement:
>
> T_loss = T_before + (T_after - T_before) * Dist(S_loss,
>S_before)/Dist(S_after, S_before)
>
>where
>
>Dist(Seqno_A, Seqno_B) = (Seqno_A + 2^48 - Seqno_B) % 2^48
>
>--> This would make the confusing comment on "wrapping sequence
numbers"
>on page 19 unnecessary.
ADDED to implementation section.
>--------------------------------------------------
>7) Gerrit - Section 6.3.1 (at the end):
>There is a half-finished sentence which tackles a new issue (first loss
>event starts with ECN marked packet), but this is left half-finished.
ALREADY DONE.
>--------------------------------------------------
>8) Arjuna - Section 6 :
>
> "If the sender is transmitting at a high rate (many packets per RTT)
> there may be some advantages to sending periodic feedback messages
> more than once per RTT as this allows faster response to changing
> RTT measurements, and more resilience to feedback packet loss.
> However, there is little gain from sending a large number of
> feedback messages per RTT. "
>
>So how do we send periodic feedback messages? What would the sender do
>when it receives periodic feedback messages per RTT? These questions
>SHOULD be answered.
DONE.
>--------------------------------------------------
>9) Gorry - 4.5
>This seems to me to describe idle periods, to me these are different
>from the concept of data-limited (e.g. taken from FR draft). I think
>this also should be mentioned in the draft.
DONE.
>I have problems in some places identifying whether X is the ACTUAL rate
>of transmission, or the maximum permitted rate. With a data-limited
>sender, these two rates do not necessarily coincide.- or is tyhis just
>my read?
CLARIFIED.
>--------------------------------------------------
>10) Gorry - RFC3448 would have benefitted from a clear defintion of
terms.
>
>Terms that would beneft from definition at the front of the document
>include:
>
>delta
>DF - discount factor
>last_counter - greatest received value of the window counter
>nofeedback timer -
>
>min_rate - Minimum transmit rate
>MSS - Maximum Segment Size (constant)
>n - number of loss intervals
>NDUPACK - Number of dupacks (constant)
>p - Measured Loss Event Rate
>p_prev - previous value of p
>q - Filter constant for RTT (constant)
>q2 - Filter constant for long-term RTT (constant)
>R - Estimated path round-trip time
>R_sample - Measured path RTT
>R_sqmean - Estimated long-term RTT
>s - Nominal packet size (constant)
>S - Sequence Number
>t_gran - schedular granuality (constant)
>t_ipi - Calculated inter-packet interval
>t_mbi - Maximum RTO value of TCP (constant)
>tld - Time Last Doubled
>t_now -
>t_RTO - Estimated RTO of TCP
>X - base transmit rate
>X_calc -
>X_pps
>X_recv - Measured transmit rate
>X_inst - Instaneous tranmsmit rate
>W_init - TCP initial window (constant)
>
>
>In section 4.7
>t_0 - initial send time
>t_1 - nominal send time
>t_2 -
>t_i
>
>Section 5.2, please also define:
>T_loss
>S_max
DONE.
>--------------------------------------------------
>11) Gorry - Section 6.2:
>Is R_m a different concept to R_sample earlier?
>Or is R_M actually R_sample?
FIXED.
They are different. Explained. R_m: sender's estimate of RTT.
R_sample: sender's sample.
>--------------------------------------------------
>12) Gerrit - Section 5.5:
>"As described in Section 5.4, the most recent loss interval
> is only assigned 1/(0.75*n) of the total weight [...]".
>
> While in the special case of n=8 happens to be true, due to
>
> w_0 / W_tot = w_1 / W_tot = 1/6 = 1 / (3/4 * n),
>
>the general case (in particular when n is odd) is more complex and
>involves quite a lot of calculation. Hence, the statement should be
>qualified that this is for n = 8.
DONE.
>-----------------------------------------------------------------------
------
>13) Gerrit - Section 3.1:
>
> | delta ==> would it not make more sense to call this t_delta ???
> | t_now - Current time
> | X - Allowed sending rate (?)
> | X_calc - Value of TCP throughput equation given s, p, R
DONE. I changed X_calc to X_Bps.
> ==> Further comment for section 3.1: it should actually read
> X_calc = s / (R * sqrt()... )
> instead of X = s / (R * sqrt() ...)
DONE.
>-----------------------------------------------------------------------
-----
>14) Gerrit - Section 4.7:
> | t_0 - initial send time
> | t_1 - nominal send time
> | t_2 -
> | t_i
> ==> I stumbled over this too and I think that the following definition
>would be clearer (used this when discussing the implementation):
>
>Let t_now be the current time and i be a natural number, i = 0, 1, ...
>Then the scheduled send time t_nom = t_(i+1) derives recursively as
>
> t_0 = t_now
> t_nom = t_(i+1) = t_i + t_ipi
DONE.
>-----------------------------------------------------------------------
--------
>15) Arjuna - Section 4.3:
>
>" Else if (not the first feedback packet, and
> not the first feedback packet after a nofeedback timer)
> If (t_now - tld >= R)
> X = max(min(2*X, min_rate), s/R);
> tld = t_now; "
>
>
>Ignoring a feedback packet may not be a good idea, since if the
>application is data-limited, (i.e., sending very few packets per
>RTT), then ignoring it would not be wise.
Fixed. Partly.
>-----------------------------------------------------------------------
--------
