[dccp] Re: [AVT] Would DCCP kill Internet real-time mediadistribution?

["Marshall Eubanks" <tme@multicasttech.com>]

On Tue, 02 Dec 2003 17:32:38 -0800
 Eddie Kohler <kohler@icir.org> wrote:
> By "real-time media", I mean "current more-or-less-CBR real-time media".
> 
> To summarize the problems that a best-effort media stream might suffer:
> (Please correct me if I'm wrong or have left anything out!)
> 
> Axiom 1: Loss sucks.  ("a 3% loss rate means a 30% reduction in quality")
> Axiom 2: Rate changes suck.  ("Have you ever actually listened ... stream
>          with varying rate? ... It sucks, to put it mildly.")
> 
> So, following this through:
> 
> * Say there's no loss.
> 
>   If there's no loss, DCCP and UDP are equivalent, except that DCCP
>   enforces slow-start.  Slow-start will not matter for low-rate flows like
>   most VoIP flows.  It will for higher-rate flows like the 4 Mb/s video
>   flow Brian Rosen has mentioned.  A TFRC/DCCP flow could probably
>   slow-start up to 4 Mb/s in 7 or 8 round-trip times, in the absence of
>   loss.
> 
>   You might also have to slow-start after a quiet period, but this could be
>   addressed by the application by sending some probe traffic.  NOT 2x the
>   nominal rate; 1/2 the nominal rate, or perhaps some more clever scheme.
> 
>   If the DCCP authors need to solve the quiet-period problem, then we will
>   try to solve it.  But the current choice -- either send 1/2 the nominal
>   rate during the quiet period, or slow-start after the quiet period --
>   doesn't seem like a killer for all real-time media distribution.
> 
> * Say there's loss.
> 
>   Well, performance already sucks by Axiom 1 :)  UDP would have suffered the
>   same loss.  The problem is whether or not DCCP reduces its rate,
>   violating Axiom 2.
> 
>   TFRC by design reduces its rate far more slowly than TCP would.  A single
>   loss will not greatly affect the rate.  TFRC seems well-protected against
>   probing TCP flows and/or a low background loss rate.  We will allow
>   applications to send at slightly above the TFRC rate as well.  So
>   probably the situation is not that bad.
> 
>   Despite this, though, TFRC may reduce the allowed sending rate to below
>   the application's nominal rate.  The application can react to this
>   however it would like.  For instance, it could stop sending, which I
>   think is the only other best-effort alternative on the table.  But if the
>   application *wanted* to, it could try to do better.
> 
> So, I think No, DCCP would not kill Internet real-time media distribution.
> 
> If these arguments aren't sound, we'd really like to hear it.
> 

On the Internet2, I would estimate that a substantial fraction of the loss that I
see in multicast UDP streaming is not due to congestion, in many cases > 50%. How
would DCCP respond to such false congestion signals ? Is there a CETEN like mechanism
to deal with this ?

Regards
Marshall Eubanks


> Eddie
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


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