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

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 3 Dec 2003 08:29:59 -0500

Hi Marshall,

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

What are the causes of these non-congestion losses?

Tom Phelan

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

---

From: [email-masked]
Date: Wed, 3 Dec 2003 16:55:36 +0100

Rosen you wrote:

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

I though this was already resolved ?

case A: you have recent codecs and you *can* change the rate,
(only of course not drastically due to the quality differences
already mentioned, but again systems with moderate rate changes
have been deployed and running for years in MPEG-2 DTV )

case B: your codec is strict CBR and then you need to tweak something
so that this CBR stream is transmitted with some variable amount of garbage
(this seems like an horrible shame to me but it seems also it would work)

Is that correct ?

regards,

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

---

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

> > Is the sense of the avt group really that slow start is completely
> > 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.
Where does it say that?

Right now, we send UDP.  It actually works pretty well, but it
clearly doesn't work if you have a bunch of TCP sources gobbling
up the bandwidth.  DCCP is not going to change the effect of TCP
on the media, it's going to change the effect of the media on
TCP.  We don't need no DCCP.  "Fair" to media is all or nothing,
Philippe's ideas notwithstanding.  Nothing is fair if the alternative 
is garbage. 

If your goal is to prevent what is today mythical congestion
collapse, then we would be much better served by talking
about how signalling can get loss rates so that it can shut
down flows.  That's simple, and it won't screw anything up.

Brian

> 
> 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.)
I'll agree with this, although I'm also willing to work on solutions.

> 
> 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?
Sorry, but as you might imagine, I don't agree. See the note from
Henning.  We use 4M, while other systems might use 768K.  That's no
reason to have any difference in protocols.  Slow start is not
a practical thing for interactive use, sorry.

---

From: Sally Floyd <[email-masked]>
Date: Thu, 04 Dec 2003 15:02:29 -0800

Brian -

>Slow start is not

I have not read all of the earlier email, so I might be repeating
things that have already been said.

Currently, slow-start for TCP allows an initial window of up to
four packets.  The reason that the Internet still works plausibly
well even with interactive traffic that does not obey slow-start
is that the vast majority of the packets in the Internet still use
TCP, and still abide by slow-start and the other mechanisms of TCP
congestion control.  If the majority of the traffic on a congested
link was interactive traffic that did not use slow-start, and that
also did not use any admissions control or explicit feedback from
routers allowing high initial windows, I don't think that any of
the interactive users would be very happy with the results.  This
would particularly be true, I would conjecture, in a network with
only interactive traffic, with no TCP traffic to back off and make
space for the interactive traffic.

For a best-effort network that includes TCP traffic, there is the
additional concern of the fairness for the TCP users.  There is no
reason why best-effort interactive UDP traffic has a higher right
to bandwidth or to low delay that does the best-effort TCP traffic
(whose users are paying the same monthly fees to their service
providers).  Remember that the TCP traffic could easily be someone
doing a web transaction that is perfectly important to them or to
their business, and for which they are expecting the same prompt
response times from the network that the interactive users are
expecting.

My own prediction is that, if there seems to be a danger of congestion
in best-effort links due to best-effort UDP traffic that is not
TCP-friendly, the routers at the congested links would end up
preferentially dropping the UDP traffic in times of high congestion
(since this is easier than more precisely-targetted forms of
preferential dropping at the router).  But maybe things will work
out better than that, and routers will have mechanisms to precisely
identify those flows that aren't using decent end-to-end congestion
control in a time of high congestion, and preferentially drop packets
from only those flows.  No telling...

- Sally
http://www.icir.org/floyd/

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 9 Dec 2003 16:08:40 +0200

There is another application (other than video, that is)
that is potentially high-bandwidth and has problems with
slow-start.

I am speaking of TDM pseudowires
(as being standardized in the PWE3 WG).

One can carry an E1 or T1 (or several of them)
over the public Internet, although higher rate TDM services
probably require dedicated networks.

Not only is TDM an inherent constant rate service,
it would be difficult to start it at anything other
than its full rate, since the other side requires the full
bandwidth for clock recovery, without which nothing works.

(Although I could imagine a special mechanism that sends the full
number of packets per second, but partially suppresses packet content
for the first few seconds.)

However, I am not sure whether TDM is an important case here
as the setup or pull-down of a TDM service is not a frequent event.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 9 Dec 2003 16:50:23 +0200

> Hi Yaakov,
> 
> It seems to me that the TDM connection could deal with 
> connection setup delays caused by a ramp-up period at the beginning of the 
> connection.  The connection would really begin once the sufficient rate was 
> reached.  Since after that the transmission would be at constant rate, there 
> wouldn't be any more start up problems.
> 
> Tom Phelan

There are several problem with that, as I said in my earlier email.

First, what exactly does one send before the TDM is "up to full rate"?
Arbitrarily chopped packets? 
For the structure-aware case one could enable timeslots one at a time,
but the PWE3 WG is mandating the structure-agnostic mode as the
standards-track one, and here it is not clear how one could meaningfully 
reduce the rate.

Second, the far end uses the initial period of TDM to lock onto
the TDM source clock's frequency and phase.
This task has to be relatively fast, since before then the
TDM output does not comply with the international standards
for jitter and wander, and can cause problems in the far-end TDM network.

The only thing I can see that would work is to send dummy packets
(marked as such) at a rate determined by the local TDM clock, 
and increasing their size until full bandwidth is attained.
Thereafter the dummy marking is removed and the true data sent.

By using such a mechanism the TDM clock could be acquired
without meaningful TDM data being lost or corrupting the far-end network.

Y(J)S