Re: SV: DCCP voice quality experiments

[Lars Eggert <lars.eggert@xxxxxxxxxxxxx>]

Hi, Arne,

On Sep 11, 2006, at 11:01, Arne Lie wrote:
> 1. What I find difficult to understand is if your applications have  
> any
> native rate adaptation, except packet drops at sender when the  
> sender buffer
> (of 5 packets?) have been saturated.

the codecs we used don't change their rate in the presence of losses,  
no matter where they occur (send buffer or along the path.

> Is it so that *if* (and when) TFRC
> gives you an equivalent rate below G.711 rate of 95.2kbps, or  
> 39.2kbps for
> G.729, your sender WILL drop packets when using TFRC (any variant),  
> while
> the UDP system will hand the problem over to the network routers?

TFRC can cap the send rate at the sender, which UDP doesn't.

> I.e., my
> main question is if G.711 and G.729 have any methods for lowering  
> the codec
> rate output below 64 and 8kbps, respectively (by quantiser scale  
> change, or
> any other means)

No, see above. Tom has a draft on how codecs that adapt their rate  
may interact with DCCP.

> 2. You have an experimental set-up. Why do you not also set-up real
> receivers (players) so that the perceptual quality can be  
> evaluated, instead
> of, or in addition to, your "E-model R-score"

You mean use PESQ as a metric instead of the E-model? We could have  
done that, but most related work has used the E-model and we wanted  
to more directly compare our results to theirs. Also, it would have  
required additional work and we were not sure that we'd get  
significantly more precise results this way.

> 3. You use DummyNet to insert packet loss and delay. Are you  
> considering
> experimenting without DummyNet, but instead inject more real  
> traffic to
> create real router congestion? I think that will give you a more  
> natural
> environment in which you can test TFRC performance under more  
> realistic
> scenarios.

Yes, definitely. In this first evaluation, however, we wanted to be  
able to very tightly control the environment, in order to be able to  
analyze the behavior we were seeing.

We did run additional tests with multiple competing flows up to and  
past the point of congestion, to investigate the relative fairness of  
the different TFRC flavors, but these aren't in the current paper.

Lars
--
Lars Eggert                                     NEC Network Laboratories

Attachment: smime.p7s
Description: S/MIME cryptographic signature