Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide

From: [email-masked]
Date: Tue, 25 Nov 2003 16:25:18 +0100

Stephen,

Unfortunately filling the client buffer at a rate faster than the media rate
and "when you can" which introduces substancial amounts of time
(many seconds) of delay is a technique for media distribution
for which DCCP is not needed:

It is called "progressive" download, it uses HTTP and it is deployed ...

regards,

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

                                                                                                                                       
                                                   To:   "Phelan, Tom" <[email-masked]>                                          
                                                   cc:   AVT WG <[email-masked]>                                                         
                                                    (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
                                                   Subject:    RE: [AVT] RE: [MMUSIC] DCCP Media Guide                                 
               Stephen Casner                                                                                                          
               <[email-masked]>                    Classification:                                                                     
                                                                                                                                       
               Sent by:                                                                                                                
               [email-masked]                                                                                                      
                                                                                                                                       
               24/11/2003 18:27                                                                                                        

I think Tom's description of the problem as enabling DCCP to get its
fair share vs. TCP has misdirected the thinking.  The problem he
identified was that TCP's bandwidth probing will cause some loss in
the DCCP stream as well.  Here is the key: that probing will cause
exactly the same loss in an RTP/UDP stream.  It is only DCCP's
reaction to the loss that is a design question.

For interactive (delay-sensitive) media, FEC may be an option for
protecting against the isolated packet losses induced by TCP probing.
This can be achieved with less than 2X bandwidth.  But other than
removing the FEC, and possibly shifting encodings, there is not much
room for the media to accommodate any direction from DCCP to back
off.

As I've said more than once in DCCP WG meetings, these applications
don't want to be congestion controlled.  Unless there is policing in
the network that causes performance with UDP to be worse than with
DCCP, there is no motivation to change protocols.

On the other hand, for streaming media to clients with significant
buffer capacity, then the approach of sending at 2X rate (if the
bottleneck allows) until the buffer is filled is a fine idea.  During
the 2X period, if DCCP says to back off by half, the application is
still getting its necessary throughput.  After the buffer is full, the
rate will have to be 1X, but if DCCP says to back off from that as a
result of TCP probing, the buffer will cover the period until the rate
ramps back up.  The rate can go over 1x again to refill the buffer,
then back to 1X.

This isn't a new idea.  DCCP would just legitimize and standardize
it.

                                                        -- Steve

_______________________________________________
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: Greg Herlein <[email-masked]>
Date: Tue, 25 Nov 2003 08:36:53 -0800 (PST)

> Unfortunately filling the client buffer at a rate faster than
> the media rate and "when you can" which introduces substancial
> amounts of time (many seconds) of delay is a technique for
> media distribution for which DCCP is not needed:
> 

That's somewhat simplistic, really.  Progressive download has a 
similar effect but it's not controlled, and it's TCP only of 
course.

For unicast scenarios this kind of thing makes total sense if the
source is non-real time (ie, streaming from disk).  It's not much
more than an enhanced jitter buffer, really - you are just adding
some extra buffer for times when the normal real-time flow is
impaired, and a mechanism to allow the client to tell the source
to "fill me up"  and "back it off."  There need not be any extra
delay at startup, though not doing so creates a window of
vulnerability.

I'd very much like to see some standardization effort on a
protocol to support this kind of thing - perhaps an RTCP
extension?  Perhaps soemthing that can apply to TCP as well?

I'm willing to help on such an effort.

Greg Herlein
VP Engineering
Arkstream, Inc.