Re: [dccp] DCCP voice quality experiments

[Eddie Kohler <kohler at cs.ucla.edu>]

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