Hi Eddie,
I'll try to answer your second point, and I believe Lars can answer much better
the questions relating to TCP.
I disagree with part of the discussion. In Section V you say that the "second
issue" is that "The initial window during slow-start-restart is the minimum
sending rate, which is one maximum-sized packet's worth of data over 64
seconds for TFRC." This is not true. I sent mail on 6/21 pointing this out.
As RFC4342 says (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."
RFC4342 specifies the way in which the initial sending rate specified in RFC3390 is to
be calculated in this case:
"Therefore, in contrast to [RFC3448], the initial CCID 3 sending rate is allowed to be at least two packets per RTT, and at most four packets per RTT, depending on the packet size. The initial rate is only allowed to be three or four packets per RTT when, in terms of segment size, that translates to at most 4380 bytes per RTT."
The draft-ietf-tfrc-voip-05 does not mention changes in computing the initial window. The draft-ietf-tfrc-faster-restart-01 specifies:
"This document suggests a relatively simple approach to this problem. Some protocols using TFRC [RFC4342] 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 by an idle period below eight packets per RTT, for small packets."
and it also mentions that faster restart in VoIP TFRC is more restrained than faster restart in TFRC.
Looking back at the e-mail archive, there were two mails related to this:
http://www1.ietf.org/mail-archive/web/dccp/current/msg00479.html
http://www1.ietf.org/mail-archive/web/dccp/current/msg00479.html
Based on the last cited paragraph of the draft, we deduced that the rate calculation is as described in the small example below.
In Section VI, why does TFRC SP+FR+MD do poorly?
In the case of G729(A) the payload size is 20 bytes giving an initial window is 160 bytes/RTT,
by far less than what the TCP implementation allows. Since TFRC+SP+FR+MD has to increase the rate for a few RTTs until it reaches the codec's nominal rate, the delay (for the whole talkspurt) causes a quality decrease.
Or perhaps TFRC should send feedback twice an RTT
rather than once. Would that help?
The problem here is that DCCP's adaptation speed is inversely proportional to the RTT. Since the sending behavior is the same, traffic is "shaped" harder as the RTT increases. TCP suffers from the same problem, but it is somehow cancelled by the higher initial rate. Sending feedback twice an RTT would help by making the jumps in send rate less steep (assuming that the overall increase per RTT is the same in order not to make TFRC more aggressive).
Vlad
