Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media dis tribution?

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 11:54:01 -0500

I have never heard/seen a codec that can dynamically, in real time,
vary its rate in response to network conditions in a way that
is not objectionable to the user.

I have seen/heard a lot of codecs, but clearly, not all, or most,
or even a significant percentage on live networks.

Your mileage may vary.

I'm dimly aware of what Philippe is talking about, but I don't
think it does what the first paragraph above describes today.  
It does hint that it might be possible to build such a thing,
but I don't know what the tradeoffs are.  For example, what is
the effect on delay?  It's certainly not in the realm of practical
deployment in the near future for interactive media. I don't
think it's practical for deployment in the near future for
non-interactive media, but I don't know as much about that
world as I do the interactive world.

Brian

> -----Original Message-----
> From: Eddie Kohler [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2003 11:18 AM
> To: Jon Crowcroft
> Cc: [email-masked]
> Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media
> distribution? 
> 
> 
> > btw the comment on adaptive rate sucks - its correct - the 
> usertrials
> > folks at UCL did certainly show that there is little point 
> increasing the
> > quality of video/audio if you are going to have to decrease 
> it , within a
> > session, as the user experiecne contains a lot of 
> hysteresis - i.e. they
> > habituate, but the user reports the worst rate they see, 
> and variation
> > (up from that and down to it) degrade the overall 
> experience more (even
> > though the average rate may be better)....
> 
> This is surely a comment about *one* system/codec, or one 
> family -- other
> people on the list have mentioned that some codecs behave better?
> 
> E
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Dec 2003 12:19:23 -0500

Multi-party, non-multicast (central server) conferences should not be 
forgotten in this discussion. They complicate life in two ways:

- The penalty of not using silence suppression gets much larger. If you 
have a conference with 100 participants, a modern implementation would 
have one or two active inbound stream and 100 outbound (mixed) streams. 
If applications need to keep sending data to keep their place, suddenly 
inbound data volume will be multiplied by a factor of between 50 
(transmitting at half rate) and 100.

This gets worse for the typical video-follows-audio setup.

- Similarly, for a useful interactive conference, participants have to 
be able to interject and speak up immediately, with the video stream 
following instantaneously. They cannot wait multiple round-trip times as 
they'll never get a word in edgewise. Thus, there is no masking of 
ramp-up delays if you want a reasonable user experience.

(Similar considerations apply to the now very popular push-to-talk 
services. Trying to sell a service where the user has to push, wait and 
then talk does not seem like a winning proposition.)

Masking is also rather tricky for two-party audio. There was a long 
discussion in the SIP working group on this topic a few years ago, 
leading to fairly elaborate hand-offs between reservation and session 
signaling to minimize the post-pickup delay. As soon as I hit the 
'accept call' button, I need to be able to say 'hello' and be heard by 
the other side. The only masking opportunity is to start sending audio 
data 'to warm up the line' while the phone is ringing, adding more 
bandwidth consumption for the large number of calls that don't succeed. 
At $4/MB for mobile voice data, this is unlikely to be popular. (Typical 
ring-to-answer delays are about 20 seconds; average call durations for 
mobile are probably three minutes, so this immediately adds about 10% 
overhead, not counting the 60% or so of calls that fail over to 
voicemail after 30 seconds.)

I believe that there now is a suggested initial TCP windows size > 1. Is 
this correct? (If you figure a maximum acceptable network delay of 100 
ms and a typical audio/video packet spacing of 50 ms, you would be 
sending about 4 packets per RTT.)

Henning