Lars, Vlad,
Very nice work -- disturbing too: clearly work remains.
There is one thing in the draft that I don't quite understand. In Section
IV.C TCP's performance is explained as due to the presence of SACK and Limited
Transmit. Likewise at the end of Section V you say that the TCP throughput
equation is based on Reno and modern variants are more aggressive. I am not a
complete expert here, but is this true? My understanding is that the
difference between Reno and NewReno and SACK and LT and etc. simply has to do
with different algorithms for avoiding inappropriate congestion responses.
Although the TFRC RFC points out that the equation is Reno, not SACK, it also
says that "from both simulations and experiments, the differences between the
two equations are relatively minor." (No supporting documentation is provided
however.) So CCID 3's congestion behavior should be like that of SACK+LT
already. If it's not that'd be very interesting. I find the other potential
explanation -- namely that TCP's retransmissions cause losses to be
experienced as delay, and that in this scenario delay is not that bad -- more
convincing.
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."
Vlad's response, sent on 6/22, says that in the implementation, the first
feedback packet sent after the idle period will have a low Receive Rate, which
will effectively result in a transmit rate lower than the initial sending
rate. This is true, but it's actually the same as the "first issue" you
describe in Section V. I think the "second issue" is not an issue.
In Section VI, why does TFRC SP+FR+MD do poorly? You say it's because
feedback is arriving less and less frequently. What a bummer! What
concretely is going on? Or perhaps TFRC should send feedback twice an RTT
rather than once. Would that help?
Thanks so much!!
Eddie
Lars Eggert wrote:
Hi,
we finally have the results of our voice quality experiments over DCCP
written up: http://larseggert.de/tmp/2006-dccp-voip-quality.pdf
We'd appreciate any feedback you may have on this!
Thanks,
Lars
--Lars Eggert NEC Network Laboratories
