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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 09:28:49 -0500

> * 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.
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 think you can pretty safely say that slow start is a very big
no-no for interactive media.  For non-interactive media, it only
annoys you a little bit, and while not desirable, isn't fatal.

Are you really proposing that we create a new protocol that only works
for small bit rate media?  I think that's a really poor idea.
Better to work harder and fix the problem for all, or nearly all
media streams now, and in the foreseeable future.  The foreseeable
future will have multimegabit media streams.

> 
>   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.
Slow start is not acceptable, as above.
A more clever scheme might work.  1/2 nominal is not realistic,
as has been pointed out.  I suspect that "more clever" means
fixing TCP.

> 
>   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.
Maybe not, but probably enough that it isn't interesting to deploy.

> 
> * 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.
This is gobbledy-gook to me.  We already have tried to point out
that you don't change the rate, except grossly, downward only,
and only once or twice.  You do that when your loss rate exceeds
some threshold.  You don't need any new mechanism to do this.

So "reducing its rate far more slowly" is not possible for the media
streams.  There is no "send at slightly above the TRFC rate".  The
rate is fixed; TRFC can't tell the media stream anything interesting.

> 
>   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.
Same issues.  There is no "nominal rate" there is only the fixed rate.

> 
> 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.
I don't think they are sound:
	Slow start is not acceptable
	TRFC is not useful/acceptable
	There is only very limited rate change, we already have the
		mechanisms to do it

DCCP isn't solving any problem that UDP has for media streams.

Brian 

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

---

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

> the "hello" pretty badly.  If it's 7-8 RTTs, you will definitely have

Hm.  I think users are pretty used to startup delays of far more than 1
second when making telephone calls.  The application can mask this easily.

Is the sense of the avt group really that slow start is completely
unacceptable for any important media flows?

> rate is fixed; TRFC can't tell the media stream anything interesting.

First, not all applications cannot change the rate, as people have
mentioned.

Second, TFRC provides you with a reference rate.  For fail-stop CBR
applications, this reference rate could be taken as an indication of when
the application must stop.  When I said "the rate changes slowly", it was
simply to point out that TFRC changes its reference rate slowly.  Thus, a
fail-stop CBR application would not be forced to stop after a small number
of losses -- only after the loss rate really changed.

Eddie

---

From: Eddie Kohler <[email-masked]>
Date: Wed, 03 Dec 2003 09:12:45 -0800

> unacceptable for any important media flows?

Also, for what it's worth, I do understand and sympathize with the problems
that slow start can cause a truly-CBR application.  I don't think
slow-start is all peaches and cream.

The problem is, Best Effort Public Internet == Slow Start.

There are proposals to eliminate the need for slow-start through explicit
feedback from routers (XCP, QuickStart), but they're a ways off.  Maybe
media will be the app that pushes them through Cisco?  Significant TCP
changes are probably even less likely.  (They're certainly less likely
without any proposal on the board.)

In the meantime, we really do have a situation where a media application
should either do slow start or something similar, or it should stay off the
public internet.  Brian, I'm coming to the conclusion that your app should
stay off the public internet -- or you may need to change the app so that
it will work best off the public internet, when it can get a true bandwidth
reservation.  Maybe that's OK for how your app is used in practice?

Eddie

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 Dec 2003 09:59:33 -0500

(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/

---

From: "mohan" <[email-masked]>
Date: Tue, 9 Dec 2003 10:46:40 +0530

----- Original Message -----
From: "Mark Allman" <[email-masked]>
To: "Rosen, Brian" <[email-masked]>
Cc: "'Eddie Kohler'" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, December 08, 2003 8:29 PM
Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
distribution?