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

From: Eddie Kohler <[email-masked]>
Date: Tue, 02 Dec 2003 17:32:38 -0800

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

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

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 02 Dec 2003 21:32:00 -0500

On Tue, 02 Dec 2003 17:32:38 -0800
> 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

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 02 Dec 2003 18:37:22 -0800

> 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 ?

NB: DCCP is unicast.

But DCCP does in fact have a mechanism, called Data Dropped, for
differentiating congestion losses from non-congestion losses (such as
receive-buffer or corruption losses).  Non-congestion losses aren't treated
as congestion, as long as we _know_ they weren't due to congestion.

Eddie

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 03 Dec 2003 07:46:53 +0000

>>would DCCP respond to such false congestion signals ? Is there a CETEN like mechanism

1/ do you mean half the time that you see loss, or that you see 50% loss? i'venever seen any loss level like that
except on a severaly broken network, where no amount of dumb CBR streamed UDP or  clever adaptive dccp will be any
use nor will TCP btw

2/ deploy ECN. that will let you cope with non congestive loss through other means - hey, >10% loss is the
Internet's way of just telling you "NO"

[its called CALL BLOCKING in phone nets, but people just dont seem to get that:-)

btw the comment on adaptive rate sucks - its correct - the usertrials folks at UCL did certainly show that there is
little point increasing the quality of video/audio if you are going to have to decrease it , within a session, as
the user experiecne contains a lot of hysteresis - i.e. they habituate, but the user reports the worst rate they
see, and variation (up from that and down to it) degrade the overall experience more (even though the average rate
may be better)....

i think this points the way (sorry to say it) to a model where we do admission control for streaming based on large
aggregate measurements and ECN, and not to rate adaption but i know this is heretical

technically, one can estimate a rate over the multiple RTT time scale via TFRC but the question is what do do about
large scale fluctuation in the load at a bottlenect ...and it seems to me that we dont have a story here yet, even
though we've been muckng about with this stuff for about 15 years...

cheers

j

---

From: Eddie Kohler <[email-masked]>
Date: Wed, 03 Dec 2003 08:18:28 -0800

> btw the comment on adaptive rate sucks - its correct - the usertrials
> folks at UCL did certainly show that there is little point increasing the
> quality of video/audio if you are going to have to decrease it , within a
> session, as the user experiecne contains a lot of hysteresis - i.e. they
> habituate, but the user reports the worst rate they see, and variation
> (up from that and down to it) degrade the overall experience more (even
> though the average rate may be better)....

This is surely a comment about *one* system/codec, or one family -- other
people on the list have mentioned that some codecs behave better?

E