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
