[dccp] Would DCCP kill Internet real-time media distribution?

[Eddie Kohler <kohler@icir.org>]

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.

Eddie

_______________________________________________
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