Subject: [AVT] Re: [dccp] Re: DCCP Media Guide

From: [email-masked]
Date: Wed, 26 Nov 2003 09:36:40 +0100

Stephen,

you wrote:

>> > 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 ...
>>
>> That's somewhat simplistic, really.  Progressive download has a
>> similar effect but it's not controlled, and it's TCP only of
>> course.
>
>Yes.
>

I am concerned that since the barrier for DCCP is very high
(implementing a new protocol at IP level is not something the industry
will go for without a strong incentive) the added value must be equally high.

My point was that Progressive download (although different of course ;-)
has pretty similar performances compared to the solution/application you describe,
i.e. media delivery with large buffers/delays....

But progressive download has *zero* hurdle(e.g. NAT/FW traversal ;-)...
so if we conclude that DCCP is good only for that application
there is the clear risk that this will not help promote DCCP...

>The key difference is that TCP insists on 100% reliability.  It must
>retransmit a lost packet before any subsequent data can be delivered.
>For these media applications, retransmission may still be useful, but
>you want the application to have control over the decision to
>retransmit or to give up and continue on.

I fully agree this is the fundamental reason why another protocol than TCP
is a good idea: media does not need 100% reliability.

The other idea I have been trying to advocate for a while because I believe it is another key to the problem
is that media does not need to be constant bit rate, nor constant packet rate, nor constant packet size.

These 3 things (delay, reliability, variable rate/packaging) should give some slack
for the design of a solution with added value no?

regards,

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Nov 2003 08:59:23 -0500

> is a good idea: media does not need 100% reliability.

The only reason not to get 100% reliability is that relaxing reliability 
constraints reduces delay, as even modest loss rates, if unfortuitously 
placed, can wreak havoc with user experience. For the higher-latency 
streaming application contemplated here, it is unclear that removing 
reliability adds any significant value, particularly given that you end 
up having to add some protection (FEC) to deal with losses, thus 
increasing the overall average bit rate or reducing the quality. 
(Obviously, FEC doesn't deal well with loss spurts, so quality will be 
rather poor if losses are indeed bursty, even with aggressive FEC.) 
Typical FEC overhead for useful error resiliency is usually in excess of 
20%, so the bandwidth penalty is substantial.

Thus, before accepting that DCCP is the right thing for streaming media, 
a bit more human-factors and measurement evidence seems called for.

---

From: Greg Herlein <[email-masked]>
Date: Wed, 26 Nov 2003 06:18:28 -0800 (PST)

> I fully agree this is the fundamental reason why another
> protocol than TCP is a good idea: media does not need 100%
> reliability.

I don't agree.  *Some* media does not need 100% reliability.  
But many video codecs have pathetic performance in the face of
packet loss - and FEC is not always a good solution (impact on
bandwidth is one reason - complexity is another).  Audio is often 
a lot more tolerant (at least in VoIP) - a loss spurt in video is 
radically painful for the viewer in most cases.

While TCP does have it's own problems for video delivery (and
some advantages too) it's not the ideal solution, clearly.

I most wholeheartedly agree that delay, reliability, variable
rate/packaging are the three elements that *can* be adjusted to 
modify the performance of a video stream.  To that I would add 
dynamic buffering at the endpoints (goes with rate, I guess).  
I'd like to see a protocol (or extension) that can implement this 
into apps that can use it to good measure, as opposed to 
generating YAP (yet another protocol) that addresses only one 
aspect of the problem (and in only one way).

Greg Herlein
VP Engineering
Arkstream, Inc.

---

From: Greg Herlein <[email-masked]>
Date: Wed, 26 Nov 2003 06:18:28 -0800 (PST)

Greg Herlein
VP Engineering
Arkstream, Inc.

_______________________________________________
dccp IETF mailing list: [email-masked]
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html