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.
h.balan@xxxxxxxxxxxx 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 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."
Question 2) Is the rate of eight packets per RTT the minimal rate
of the protocol even in periods of non-idleness?
No. In periods of heavy congestion, the allowed rate can drop below
eight packets per second, just as in TCP, the allowed rate can drop
below the initial sending rate. But see below.
Relating to the
previous question, should the averaged packet size or the nominal
packet size of 1460 bytes be used in the calculation of the rate?
We have not specified a combination of Faster Restart and Smaller
Packet variants yet. Faster Restart could be applied to either the
normal TFRC or to TFRC-SP. If applied to TFRC-SP, then as above, the
nominal size s=1460 is used, and the eventual sending rate is adjusted
by s_true/(s_true+H) as a last step.
In case the answer to the previous question is affirmative, should
the rate calculation at the end of section 3. become:
"If p > 0,
Calculate X_calc using the TCP throughput equation.
X_recv_limit := 2*X_recv.
If X_recv_limit < X_fast_max,
X_recv_limit := min(4*X_recv, X_fast_max).
X := max(min(X_calc, X_recv_limit), 8*s/R). <= changed minimal
rate
This is not correct.
X := max(min(X_calc, X_recv_limit), s/t_mbi)
Else
If (t_now - tld >= R)
X := max(min(2*X, 2*X_recv), 8*s/R); <= changed minimal rate
Again, not correct.
tld := now."
Changing the minimal rate from s/t_mbi to 8*s/R while in congestion
avoidance mode shortens the time needed to reach the codec's
nominal transmission rate by log_4(8*t_mbi/R) RTTs ~= 6 RTTs for a
connection with 50ms round trip.
Ah, I see what you are missing. You are assuming that the allowed
sending rate X can drop below the initial sending rate *as the result
of an idle period*. This is not correct. RFC4342, Section 5.1:
[T]he allowed sending rate is never reduced to less than the [RFC3390]
initial sending rate as the result of an idle period. If the allowed
sending rate is less than the initial sending rate upon entry to the
idle period, then it will still be less than the initial sending rate
when the idle period is exited. However, if the allowed sending rate
is greater than or equal to the initial sending rate upon entry to
the idle period, then it should not be reduced below the initial
sending rate no matter how long the idle period lasts.
So if X > INITIAL_RATE before the idle period, then X_recv is defined
as INITIAL_RATE/2 at the end of the idle period, allowing the sender
to initially send at X_recv_limit = 2*X_recv = INITIAL_RATE. (Using
faster restart X_recv would actually be defined as INITIAL_RATE/4.)
I hope this clarifies things.
Eddie
Vlad Balan
