Thank you for the clarifications, and I hope you will not mind some further
questions.
Regarding my assumption that the sending rate can drop below the initial
sending rate as a result of an idle period, I would like to explain why
this
takes place, at least in our experimental setup:
I mentioned that we were using CCID 3 (on a BSD implementation, not the ns
version of TFRC) and we modified it in order to work with the equations
presented in the small packets and the faster restart draft. The CCID 3
draft
introduces the new feedback mechanism, based on window counters, in
which the
receiver sends a feedback about once per RTT (same as TFRC), but only as
long
as there are data packets arriving from the sender. As the receiver
feedback
and the sender's idleness detection are quite independent, there is no
way to
associate a feedback packet to a period of idleness, except if the feedback
packet arrives while the the sender is in the idle state, in which case the
provision not allowing the rate to go below 1/2*INITIAL_RATE would be
applied.
However, the first feedback packet after the period of idleness arrives
as a
reply to one of the first data packets send after the idle period, after
the
sender has exited the idle state. This feedback packet will report a
receive
rate computed using the whole time interval since the last feedback (sent
before the idleness period begun) in the denominator, giving quite a low
receive rate, which, since it is reported during the new active period,
limits
the sender's send rate.
Regarding the faster restart:, the draft says:
This document suggests a relatively simple approach to this problem.
Some protocols using TFRC [CCID 3 PROFILE] already specify that the
allowed sending rate is never reduced below the RFC-3390 sending
rate of four packets per RTT during an idle period. Faster Restart
specifies that the allowed sending rate is never reduced below eight
packets per RTT, for small packets. In addition, because flows
already have some (possibly old) information about the path, Faster
Restart allows flows to quadruple their sending rate in every
congestion-free RTT, instead of doubling, up to the previously
achieved rate. Any congestion event stops this faster restart and
switches TFRC into congestion avoidance.
I am confused here, after reading the reply, regarding the packet size
in the send
rate calculation. The quoted paragraph seems to suggest using s =
average packet
size, instead of s = 1460 bytes. The difference is significant, since
a rate of
8*1460 bytes/RTT is likely to be well above a voice codec's needs, as
opposed to sending
eight small packets in the first RTT. For this reason, I would like to
know which of the two
methods of computation (using one of the two choices for the packet
size) should be used
in deciding the bound for the minimal rate during a period of idleness.
Best Regards,
Vlad Balan
Eddie Kohler wrote:
Hi Vlad, sorry for the delay. I will try to answer these questions as
best I can.
[EMAIL PROTECTED] wrote:
We are sending interactive voice traffic over CCID 3(RFC4342) (also
its variant for small packets draft-ietf-dccp-tfrc-voip-05.txt and
the variant for small packets with with faster restart draft-ietf-
dccp-tfrc-faster-restart-00.txt), trying to observe the impact of
the protocol on the end-to-end quality. Since the codec uses
silence suppresion, our traffic contains periods of data
transmission alternating with periods of idleness, and due to the
fact that we experience frequent slow start (we can only double our
transmission rate during one RTT), the minimal rate of TFRC is an
important factor affecting the transmission quality.
We kindly ask you for some clarifications regarding the way in
which the rate is set in the case of TFRC for small packets and its
faster restart variant.
RFC 3448, section 4.3 states:
If (p 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
Else
If (t_now - tld = R)
X = max(min(2*X, 2*X_recv), s/R);
tld = t_now;
while draft-ietf-dccp-tfrc-voip-05.txt requires the nominal packet
size s to 1460 bytes;
Question 1) Should s=1460 bytes be used in the factors s/t_mbi and
s/R ? If so, should they be corrected by a factor s_true / (s_true
+ H) accounting for the header size?
The difference between the two methods is significant in the case
of VoIP packets, reaching over an order of magnitude.
s=1460 bytes should be used in those factors, yes. The correction
X := X * s_true / (s_true + H) is applied to the calculated value of
X in both cases; it is not applied to s itself.
draft-ietf-dccp-tfrc-faster-restart-00.txt states:
This document suggests a relatively simple approach to this problem.
Some protocols using TFRC [CCID 3 PROFILE] already specify that the
allowed sending rate is never reduced below the RFC-3390 sending
rate of four packets
