Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 24 Nov 2003 09:49:03 -0500

Magnus

I don't think the people working on the stability of the network
understand what they are proposing, or they wouldn't be proposing it,
except for Tom, who probably understands what the effect of 2X
bandwidth (when congestion was not occurring), and figures if that's
the only knob he's got, then he turns it far enough to make his app work,
and since he doesn't violate any rules, all is well.

I don't agree.  I think that, as Marshall observes, RTP media flows
tend to be self policing, and in any event, following the IAB
recommendation of dropping the flow if excessive packet loss is observed
will have the same effect - congestion collapse will not occur.
I think that we should stop thinking that we need anything else to
prevent congestion collapse.  

I think the real question this thread is addressing is whether DCCP
is at all suitable for real time flows.  I think the answer is no.
I think we should try see if we can reach consensus on this.
Given what has been said on this thread, is there anyone left who
thinks DCCP is suitable for RTP flows?  

This leaves us in a quandary, which, I think, is what Tom was trying to
avoid.  If DCCP is not suitable, is there any way to hold off the greedy
TCP?  This is the question Mike raises.  It's not an issue of congestion
collapse, it is the issue of "fairness".

My own feeling is that fairness to RTP is let the flow go through or don't.
There exists a variety of ways to vary the rate, but none of them are
useful.
Have you ever actually listened (or watched) a media stream with varying
rate?  I have, several times, several different algorithms.  It sucks, to
put it mildly.  Unless you have some evidence that there exists an
algorithm which does not annoy a user when the rate changes, I suspect 
our experience will be the common one - you will go down, once, and 
never go back up.  I expect even this will be very rare.   Much more common
is that you will try one rate, and if you don't get good results, the
call/stream will be dropped and tried again.  There are lots of algorithms
to vary rates.  There are no ways I know to vary quality, how ever it is
done,
and not be very distracting to a user.  Unless there is some kind of
concealment mechanism I am not aware of, it just won't be used, regardless
of how clever the algorithm is, and how bandwidth efficient it is.

So, to me, the idea that RTP reacts to whatever else is happening in any
way other than dropping the entire stream is not credible.  That means
there is no real rate control for RTP, TCP friendly or otherwise.
(I'll just use RTP vs TCP, even though we all understand that RTP is
carried on some other transport at the same level as TCP).

So what does it mean to be "fair"?
	For RTP, being fair to TCP (or other best effort traffic) is to
		not get started, or get dropped if congestion is excessive
	For TCP, being fair to RTP (or other constant rate traffic) is
		to not be greedy.

This is why QoS mechanisms work.  If you put RTP ahead of TCP,
and use admission control to limit the amount of RTP, everything works.
If you don't have a QoS mechanism, you can still perform admission
control to the RTP flows to enforce RTP fairness on TCP, but you need
to put some kind of mechanism to allow TCP to be fair to RTP.  I'm happy
to work on mechanisms that would afford effective admission control
in reaction to best effort traffic, but only if there is a commitment
to fix TCP.

Brian

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, November 21, 2003 10:40 AM
> To: Rosen, Brian
> Cc: Phelan, Tom; [email-masked]'
> Subject: Re: [AVT] RE: [MMUSIC] DCCP Media Guide
> 
> 
> Hi Brian,
> 
> I don't think that the people working with stability of the 
> network are 
> sharing you view due to the implications that your claims results in.
> 
> First, if a multi-media application transmitting data over a 
> best-effort 
> IP network, i.e. without any QoS guarantees across the whole net that 
> its traffic will fit, it can definitely cause congestion 
> collapse if the 
> mix becomes most, media, little TCP. Please read 
> draft-iab-congestion-01.txt for some discussion on this.
> 
> Some comments to your assertions.
> 
> Rosen, Brian wrote:
> > Phillipe
> > 
> > You have made invalid assumptions:
> > 	1. That audio/video media data rates will be changed dynamically
> > 		as network traffic changes.  This is very 
> unlikely.  It may
> > 		be that you get so much loss that you drop to a 
> lower data
> > 		rate, although I suspect that will be rare.  
> When you do,
> > 		you will never revert to the higher rate.  This 
> is because
> > 		humans hate to see the change, and minimizing 
> changes is 
> > 		more desirable than keeping average quality higher.
> 
> First you agree that it is possible to change the rate. Secondly I 
> understand that the there are implications on switching rate, i.e. 
> quality to often, however there are reasons for switching up when the 
> quality gain of a switch if being possible to keep the new 
> rate is clear.
> 
> > 
> > 	2. Real Time apps have no interest in being "fair".  
> They are all
> > 		or nothing. If you admit them to the network, you expect
> > 		the streams to be maintained.  If you can't 
> maintain them,
> > 		don't start them.  They don't want to be fair 
> to TCP, and
> > they
> > 		don't want to be fair to other RTP.  They just 
> want to send
> > 		data at the rate they were advised to do by signalling.
> > 		They can tolerate some loss.  Misordering=loss. 
>  Duplicates=
> > 		wasted bandwith.  That's a whole lot different from TCP
> > 		traffic.  
> > 
> 
> Yes, I agree that the application has no interest in being 
> fair. However 
> using best effort networks requires one to being reasonably 
> fair. If one 
> are not, the combination of several of media application can totally 
> destroy things for them self.
> 
> > I can imagine working on protocols which allowed CBR and 
> "best effort"
> > traffic to better coexist, but I think it's only possible 
> if the best
> > effort traffic recognized the presence of the CBR traffic 
> and reacted
> > appropriately.  Otherwise, you need to use QoS mechanisms 
> to separate
> > the traffic.
> 
> What says that the media traffic is more important that the traffic 
> going over TCP?
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 

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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 24 Nov 2003 10:34:01 -0500

Been watching this thread. Throwing caution to the wind and jumping in...

> and since he doesn't violate any rules, all is well.
A factor of two of breathing room for a single low-rate audio session is 
one thing. A factor of two on a multi-megabit video flow is quite another. 
I think we need to take some factors into account:

a) nearly all the deployed coders, both audio and video, are CBR. More 
importantly, they have extremely limited dynamic range on packetization 
period, and hence on PPS generated by a transmitter. Schemes which switch 
coders based on feedback are possible, but don't help much with the PPS 
part and run into the human factors problems Brian mentioned in an earlier 
post. I'm not enough of an expert in this aspect to have a useful opinion, 
except to say that if the results of switching coders is less annoying than 
dropping lots of packets or dropping the whole flow, then it may still be 
worthwhile.

b) VBR coders are a possibility, but it is not clear that they have enough 
dynamic range (2x for audio, maybe 3x for video) to make a significant dent 
in congestion events. There is also the problem of whether they can adapt 
quickly enough (i.e. 1 RTT) to play nice in a world with greedy TCPs that 
go over the edge rather than throttle back gracefully using ECN.

c) I suspect Tom's 2x bandwidth scheme would not be "necessary" if all the 
TCPs did ECN. True or false?

> prevent congestion collapse.
I agree with this, and this seems to cut to the fundamental architectural 
fact-of-life - realtime media streams have very limited ability to adapt to 
congestion.

> thinks DCCP is suitable for RTP flows?
I suspect that DCCP will be of very limited utility for *interactive* 
realtime flows, where end-to-end delay has to fit within human interaction 
timescales (1/4 second or less). However, there's a baby in the bath water, 
which is realtime media streaming/distribution, where DCCP may be a big win 
compared to either UDP or TCP encapsulation for RTP.

> My own feeling is that fairness to RTP is let the flow go through or
> don't. There exists a variety of ways to vary the rate, but none of them
> are useful.
I mostly agree with this.

> put it mildly.
The question is whether it sucks worse than persistent x% loss or sucks 
worse than denial of service. At some loss/delay level it is in fact better 
to drop the flow than try to adapt. I think we need to think in terms of 
which impairment is worse rather than trying to convince people that 
adaptation will be good enough so people don't notice.

> Unless you have some evidence that there exists an
> never go back up.  I expect even this will be very rare.   Much more
> common is that you will try one rate, and if you don't get good results,
> the call/stream will be dropped and tried again.  There are lots of
> algorithms to vary rates.  There are no ways I know to vary quality, how
> ever it is done,
I'm not quite as pessimistic as Brian but I believe the onus is on those 
who propose congestion adaptation schemes to show that they work from a 
human-factors perspective rather than on the media folks to put up with 
whatever loss and delay behavior congestion adaptation forces upon them.

> and use admission control to limit the amount of RTP, everything works.
Yes...but...we'd like to have less state-heavy admission control schemes 
which do measurement-based admission control, which puts us to some extent 
right back  where we started.

> in reaction to best effort traffic, but only if there is a commitment
I'd like to understand why ECN won't bring the TCPs down enough in 
greediness to avoid badly increasing the delay/loss behavior of the RTP 
flows.

Dave.

>> Multimedia Technologies, Ericsson Research EAB/TVA/A

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Mon, 24 Nov 2003 09:27:25 -0800 (PST)

I think Tom's description of the problem as enabling DCCP to get its
fair share vs. TCP has misdirected the thinking.  The problem he
identified was that TCP's bandwidth probing will cause some loss in
the DCCP stream as well.  Here is the key: that probing will cause
exactly the same loss in an RTP/UDP stream.  It is only DCCP's
reaction to the loss that is a design question.

For interactive (delay-sensitive) media, FEC may be an option for
protecting against the isolated packet losses induced by TCP probing.
This can be achieved with less than 2X bandwidth.  But other than
removing the FEC, and possibly shifting encodings, there is not much
room for the media to accommodate any direction from DCCP to back
off.

As I've said more than once in DCCP WG meetings, these applications
don't want to be congestion controlled.  Unless there is policing in
the network that causes performance with UDP to be worse than with
DCCP, there is no motivation to change protocols.

On the other hand, for streaming media to clients with significant
buffer capacity, then the approach of sending at 2X rate (if the
bottleneck allows) until the buffer is filled is a fine idea.  During
the 2X period, if DCCP says to back off by half, the application is
still getting its necessary throughput.  After the buffer is full, the
rate will have to be 1X, but if DCCP says to back off from that as a
result of TCP probing, the buffer will cover the period until the rate
ramps back up.  The rate can go over 1x again to refill the buffer,
then back to 1X.

This isn't a new idea.  DCCP would just legitimize and standardize
it.

                                                        -- Steve