Subject: [MMUSIC] RE: [dccp] rapid rate change codecs (was ... something else!)

From: [email-masked]
Date: Fri, 25 Jul 2003 18:10:05 +0200

Hi, Tom, Eddie,

(just sending to the lists now, getting too many duplicates!)

>Hi Philippe,
>
>From an e-mail from Eddie it appears that I wasn't totally correct that
>there's no penalty for sending below the maximum rate, but I don't think it
>changes my scheme.
>
>From what Eddie said, and from looking at the TFRC RFC again, I think that
>while you're sending below the TFRC max rate the max rate doesn't grow (even
>if it could).  So if you want to now increase your sending rate, the maximum
>you can send in the next RTT is twice what you just sent, regardless of how
>low the RTT is.  You need to slow-start up to the rate that you could have
>been sending if you were greedy.
>
>Tom P.

Yes,  it means that the application will have to "probe" by sending data at the TFRC rate,
which in turn means oscillating  between
* sending a "low" media rate too fast (which will fill up the player buffers)
* sending a "high" media rate too slow (which will deplete the player buffers)
to keep a constant buffer at the receiver.

(Damon: you were right, DCCP is not any progress here,
we will still need to monitor the receiver buffers as we do now !-)

for media delivery (large buffers) this is ok (assuming you have the capability to switch etc ..;-)

Unfortunately for very small buffers (i.e. small delay, VoIP) that means switching *VERY often*!

I think it leads to the conclusion that DCCP for VoIP is useful with codecs
for which the rate can be changed very often with no penalty ?

This would be OK for voice (with AMR, EVRC etc) but maybe not so much for video?

<from other mail>

>> Am I putting irrealistic hopes in DCCP?
>
>Yes. DCCP cannot predict congestion in the network.

Actually that part is ok: DCCP will tell the sender to reduce the rate,
give it a new target, this is good.

>
>You can get some of what you want, in that DCCP will tell the app the best
>rate it is currently allowing ...

Ah, but finally the irrealistic hope I was putting in DCCP is discovered:
DCCP can not tell the application when to increase its rate unless
the application "probes" the network first by ... increasing its rate.

But one who has the right codecs can live with that ;-)

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Damon Lanphear <[email-masked]>
Date: 25 Jul 2003 10:00:30 -0700

inline:

> This would be OK for voice (with AMR, EVRC etc) but maybe not so much for video?

Yes.  Video quality oscillation is going to be a big bad problem. 
Unless we have truly wonderful codecs with very fine grained scalability
(which I understand are very expensive in terms of rate efficiency), we
have to live with potentially annoying oscillations over relatively
short timescales.  So any robust video solution that uses TFRC and media
adaptation will have provide a way to exchange potential for
oscillation/maximization of quality vs. stability/lowest common
denominator quality.

-- 
Damon Lanphear <[email-masked]>