Sally, co-Editors,
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,
Best wishes,
Gorry (et al)
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.
--------------------------------------------------
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.
--------------------------------------------------
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?
--------------------------------------------------
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.
Discussion of `packet-based' versus `byte-based' is missing, perhaps
this is similar (?) to TCP.
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.
--------------------------------------------------
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).
--------------------------------------------------
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.
--------------------------------------------------
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.
--------------------------------------------------
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.
--------------------------------------------------
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.
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?
--------------------------------------------------
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
--------------------------------------------------
11) Gorry - Section 6.2:
Is R_m a different concept to R_sample earlier?
Or is R_M actually R_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.
-----------------------------------------------------------------------------
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
==> Further comment for section 3.1: it should actually read
X_calc = s / (R * sqrt()... )
instead of X = s / (R * sqrt() ...)
----------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
