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

From: [email-masked]
Date: Mon, 8 Dec 2003 17:04:52 -0000

Mark,

very interesting reading this - in paticular, your comment:

"A more general wondering of mine is how many streaming apps require this
"instant on" behavior (i.e., is your app an anomaly or is there a whole
class of apps that want instant-on over best-effort networks?)?"

I totally agree. Whilst "instant on" is really important [at the application layer] for streaming / VoD applications with trick-modes such as fast-forward, rewind, etc. (don't want buffering every time you want to scan / hop channel etc.) it should be up to the application to provide that type of functionality. It should not be up to the network / transport to cater for this.

With the new video codecs that are coming on-line (H.264 / MPEG4 pt10) and the associated streaming profiles (which enable a streaming application to switch between encoded data-rates)  it should be reasonable to design streaming apps that will provide near-instant on, but still adhere to the slow-start rules of whatever the transport protocol offers.

So, it is my belief that streaming apps do not require instant-on throughput, and should adhere to the same rules as other applications.

rgds

Matt Walker 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark
Allman
Sent: 08 December 2003 15:00
To: Rosen, Brian
Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
distribution? 

(gluing together two things that I can't get to jive together in my
head) 

> A typical RTT on the internet these days is 50-100 ms.  If you
> experience 30% loss in the first 3 RTTs of voice, you will clip the
> "hello" pretty badly.  If it's 7-8 RTTs, you will definitely have a
> very poor experience.

I do not understand where this 30% loss number comes from.  If a host
experiences 30% loss the network is *quite* congested (recent
measurments I have done show that loss rate over 10% are very rare in
the Internet) or the connection is crossing a very ratty error-prone
link.  I think the latter is unlikely in the general case.  So, how
would this:

> Yep; bang! 0 to 4Mbit in two packets.

be useful?  If you're already clipping "hello" then this is going to
provide a very lousy experience, right?

Others have said it already, so I'll just briefly agree: In a
best-effort network I do not think any particular flow (TCP or DCCP or
UDP or SCTP or whatever) should be able to just start sending at a "high
rate" (where "high rate" is undefined, but 4Mbps is certainly high).  I
think it would not be terribly difficult to show that such behavior
could easily cause problems (to competing TCP, to competing streaming
flows and to the flow that is doing this "instant on").  Slow start is
the current consensus for how to start from zero.  Could there be other
schemes?  Sure.  Are those here and fully fleshed out such that we could
even consider them as potential solutions?  Not right now.  

My hunch is that sending DCCP (/anything) through without slow start is
not going to work (i.e., I think consensus would be against that).  So,
if your app can't deal with that then I think we might be stuck ...  A
more general wondering of mine is how many streaming apps require this
"instant on" behavior (i.e., is your app an anomaly or is there a whole
class of apps that want instant-on over best-effort networks?)?

Thanks!

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

_______________________________________________
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: Stephan Wenger <[email-masked]>
Date: Mon, 08 Dec 2003 09:47:22 -0800

Matthew,

At 09:04 AM 12/8/2003, [email-masked] wrote:

>With the new video codecs that are coming on-line (H.264 / MPEG4 pt10) and 
>the associated streaming profiles (which enable a streaming application to 
>switch between encoded data-rates)  it should be reasonable to design 
>streaming apps that will provide near-instant on, but still adhere to the 
>slow-start rules of whatever the transport protocol offers.

While I'm a big fan of the extended profile of H.264, and particularly the 
SI/SP picture technology, I do not believe that there will be any 
significant deployment of these technologies in the next few years.  And 
even if there is, the problem of varying perceived qualities due to rate 
changes, and the related user acceptance problems, still exist.  (The same 
is true for all these fancy layered coding concepts that are around since 
10 years or so.  There was never any significant deployment.  I wonder, why.).

Stephan