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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Nov 2003 11:04:49 -0500

To me, this is just nonsense.
I can't imagine anyone deploying such a solution.

This is forcing the problem to fit the solution, and it's not
the right way to go.  If you want it to work, the protocol
has to take the characteristics of the flows as they are, and not
as you would like them to be.  Real time media, streaming or realtime,
is either constant bit rate, or pretty close to it.  That's how it 
works.  Our challenge is to make the protocols work with this data,
not change the data, especially silly ideas like doubling the bandwidth.

We make video telephones.  They nominally send 4 megabits.  Would
you like us to double that, under any circumstances?  

I thought not. 

Brian

> -----Original Message-----
> From: Phelan, Tom [mailto:[email-masked]]
> Sent: Thursday, November 20, 2003 10:36 AM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: [AVT] RE: [MMUSIC] DCCP Media Guide
> 
> 
> Hi Jonathan,
> 
> Thanks for the comments.  The actual proposal is to send up 
> to double the
> nominal transmit rate when there's available bandwidth, and 
> to reduce the
> rate as necessary if there isn't enough bandwidth.  This 
> doubling is to
> allow fair sharing of the chokepoint bandwidth (between DCCP 
> media apps and
> TCP apps), and to avoid what appears to me to be the 
> potential for bullying
> from TCP applications that want to suck up all the bandwidth 
> they can.  It
> doesn't preclude using low-rate codecs, or mean that the 
> access link must
> support the double rate for the connection to function well.
> 
> This recommendation was meant for best-effort environments, 
> where the voice
> traffic receives no special treatment, and must compete with 
> TCP apps for
> network resources.  I can see how this would require a 
> network that gave
> special treatment to voice packets to provision double the 
> capacity, though.
> 
> This fairness problem is difficult.  All of the research I'm 
> familiar with
> approaches it from the direction of other apps being fair to 
> TCP.  I'm not
> aware of any other methods for ensuring that non-TCP apps get 
> their fair
> share when competing with TCP.  If you (or anyone else) knows 
> of something
> I'd appreciate the pointer.
> 
> Tom P.
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Thursday, November 20, 2003 2:32 AM
> > To: Phelan, Tom
> > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > Subject: Re: [MMUSIC] DCCP Media Guide
> > 
> > 
> > Tom,
> > 
> > I don't think this solution will be acceptable to many of 
> the network 
> > providers of interactive voip services. Many of them are 
> insistent on 
> > using low rate codecs, like g.723, in order to reduce the costs of 
> > capacity in their networks. Doubling the rate would defeat 
> > the purpose 
> > of using these low rate codecs in the first place.
> > 
> > -Jonathan R.
> > 
> > Phelan, Tom wrote:
> > 
> > 
> > > Comments will be appreciated.  In particular, I make the 
> > suggestion that
> > > media apps should transmit at up to twice their nominal 
> > maximum rate, when
> > > DCCP allows it, in order to provide protection from competing TCP
> > > applications.  I know that the first time I heard someone 
> > make a similar
> > > suggestion I was horrified, but as I developed the issues 
> > it seemed to be
> > > necessary.  Reactions to this will be appreciated.
> > > 
> > > Tom P.
> > > 
> > > _______________________________________________
> > > mmusic mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> > > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > Chief Technology Officer                    Parsippany, NJ 
> 07054-2711
> > dynamicsoft
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

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

---

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 20 Nov 2003 11:47:47 -0500

Hi Brian,

Thanks for the comments.  See inline ...

Tom P.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, November 20, 2003 11:05 AM
> To: 'Phelan, Tom'; 'Jonathan Rosenberg'
> Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> 
> 

Would you prefer to be forced unnecessarily into packet loss and a lower
encoding rate by greedy TCP applications?  Or do you have another solution?

I don't think I'm forcing the problem to fit the solution, just perhaps that
the problem I'm trying to solve is different than you perceive.  The problem
that I'm trying to solve is how can an application that is content with a
maximum bandwidth compete with TCP applications that are insatiably greedy,
in a way that satisfies some concept of fairness in all directions?

The solution that I see is to provide a buffer against TCP probing.  This
would involve sending more data than is nominally necessary.  If the network
has capacity for more than 4M bps, then why shouldn't a media app make use
of it?  A TCP app would.

I must admit that my initial reactions to suggestions like this were very
similar to yours.  I encourage you to look at the draft for more detail on
the issues that convinced me otherwise.

---

From: [email-masked]
Date: Thu, 20 Nov 2003 18:22:39 +0100

Brian, all,

It may provide some help in understanding the situation
to describe your exemple as follows:

* you send video at 4 Mb/s, good.

* it happens that you are competing with (a lot of ) TCP

AND that you want to be fair to it:

* so when that happens you decrease your rate to 2 Mb/s for "a while"
because otherwise you are not fair.

* but at some moment you will want to come back up to 4 Mb/s right ?

=> the point is that the **only way**  to know if you "can" do that, is to try it....

regards,

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

                                                                                                                                       
                                                   To:   "'Rosen, Brian'" <[email-masked]>                                    
                                                   cc:   "[email-masked]'" <[email-masked]>                                             
                                                    "[email-masked]'" <[email-masked]>                                                    
                                                    "[email-masked]'" <[email-masked]>                                              
               "Phelan, Tom"                        (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
               <[email-masked]>              Subject:    RE: [AVT] RE: [MMUSIC] DCCP Media Guide                                 
                                                                                                                                       
               Sent by:                            Classification:                                                                     
               [email-masked]                                                                                                   
                                                                                                                                       
               20/11/2003 17:47                                                                                                        

Hi Brian,

Tom P.

---

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 20 Nov 2003 12:57:35 -0500

Hi Jonathan,

See inline ...

Tom P.

> Sent: Thursday, November 20, 2003 12:35 PM
> To: Phelan, Tom
> > allow fair sharing of the chokepoint bandwidth (between 
> DCCP media apps and
> > from TCP applications that want to suck up all the 
> bandwidth they can.  It
> > traffic receives no special treatment, and must compete 
> with TCP apps for
> What about networks where there is also a lot of UDP traffic? For 
> example, these same networks providing voip traffic today. If I 
> incrementally add dccp support, it seems like I will need to increase 
> the provisioned capacity so I dont push out the UDP, no?

Yes, DCCP will behave towards UDP (and vice versa) pretty much the same as
TCP behaves toward UDP.  For streaming media apps following the guidelines
in the DCCP Media Guide, it actually can be a little better than TCP versus
UDP, because there is a maximum transmit rate.

> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Nov 2003 13:23:39 -0500

I have looked carefully at the drafts.  I think I understand what 
the proposal is, and how it works.  I'll even agree that it might 
do what you think it will do, but I suspect that my device will 
cause a heck of a lot more congestion to the network if I run the 
video streams on DCCP than if I leave it on UDP.  I think the 
solution will be much worse than the problem.

The solution is just plain broken, in my opinion.  The real, hard, 
problem is that there probably is no good solution, short of fixing 
TCP, or treating real time data differently (ie QoS) in the router.  
Like it or not, RTP is not appropriate for what we usually call 
"best effort", but the problem with that statement is that it's not 
really true that we need something more than for the network to use 
its' best effort to deliver the traffic.  What is true is that other 
streams have to deal better with CBR data than they do.  It is TCP 
that is broken. I don't think there is any way around that.  
TCP makes an assumption that is invalid when real time media is part 
of the traffic mix.

There are so many problems with DCCP applied to real time media (this 
one, slow start,...), that I think we should just stop believing that 
DCCP is appropriate for RTP.

A specific comment to your message below is that if we send more data
than 4Mbit, it is just filler.  We cannot "make use of it".  We can
just congest the network more than we do.  As you might realize,
we already have problems putting 4M into the network.  More is not
better in this case.

Brian

> Sent: Thursday, November 20, 2003 11:48 AM
> To: 'Rosen, Brian'

---

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 20 Nov 2003 13:44:47 -0500

Hi Brian,

I have sympathy for your opinion.  I despair about the possibilities of
changing TCP or getting widespread deployment of suitable QoS mechanisms,
though, so I'm not quite ready to give up on DCCP yet ...

Tom P.

> Sent: Thursday, November 20, 2003 1:24 PM
> To: 'Phelan, Tom'
> Cc: [email-masked]'; [email-masked]'

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Nov 2003 17:14:23 -0500

The reason to "avoid" TCP friendly rate control is, at least so far,
because there is no way yet proposed to do it without destroying the 
usability of the RTP flow.

Part of the problem is that the only "rate control" that works is to
negotiate an acceptable rate in the signalling before the stream starts.
There really isn't any other way to change the rate, at least for
interactive streams.

For non-interactive streams, you can always buffer more, which allows
you some short term variation.  I don't think that any of the proposed
mechanisms would actually work even in that case, but maybe there is
a way to do something.  Non interactive streams need CBR averaged over
the buffer time.  That can be up to seconds in some cases, hundreds
of milliseconds in other cases, but over that interval, your goodput
must equate to the transmit offer rate times the interval (some small
loss rate acceptable).

It would be nice if there was a way.  I haven't seen one yet.

Brian

> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, November 20, 2003 5:02 PM
> To: Qiaobing Xie
> Cc: [email-masked]; 'Rosen, Brian'; TSV WG list; Phelan, Tom;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP 
> Media Guide
> 
> 
> 
> On Nov 20, 2003, at 1:26 PM, Qiaobing Xie wrote:
> 
> > Hi, Tom,
> >
> > It seems to me that you are basically: 1) questioning the 
> fairness of 
> > TCP itself
> > and, 2) you want to do something in the app level to 
> outmaneuver TCP 
> > so as to
> > achieve your term of fairness.
> >
> > I am not convinced this is the right thing to do with DCCP.
> >
> > I remember similar issue was discussed on tsvwg list (I am 
> cc'ing it). 
> > Maybe
> > people in tsvwg can share their thoughts on this as well.
> 
> 
> The fairness of TCP itself could use some questioning -- but I do not
> believe that is a reason to evade TCP friendly rate control.
> 
> Eventually, there should be a solution for proper support of 
> predictably
> variable rate flows that have fixed delivery requirements. But that 
> solution
> should be developed considering TCP, SCTP and DCCP as a whole.
> 
> 
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
>

---

From: [email-masked]
Date: Fri, 21 Nov 2003 12:49:14 +0100

>usability of the RTP flow.

I aggree this is a chalenge and especially I think that the availability
of codecs for which the rate can be rapidly changed over wide ranges is key.

>There really isn't any other way to change the rate, at least for

This is where progress must be done: there is a need for signaling
that the rate must change, during the streaming.

>a way to do something.

Stream switching is a solution.

regards,

Philippe Gentric
Chief Architect
Philips Software

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 21 Nov 2003 10:10:02 -0500

At 11:47 AM 11/20/2003 -0500, Phelan, Tom wrote:

<snip>

>has capacity for more than 4M bps, then why shouldn't a media app make use

<snip>

I think this snippet captures the essence of the argument.

An "insatiably greedy" TCP application has an infinite amount of data to
send. And "fairness" in "TCP-land" is ONLY FAIRNESS IN INSTANTANEOUS
BANDWIDTH ALLOCATION (across TCP/DCCP/SCTP connections/associations).

This is historically how TCP has been viewed. But wait ... if you delay
the "infinite amount of data" in the TCP socket .... what bad happens?
Nothing, it just takes longer (from a "work conservation viewpoint") to send
the data. Did TCP suffer? Well ... it got less work per unit time ... but
nothing really bad occurred for the "insatiable TCP" case.

Most real-time data is DELAY SENSITIVE. To real-time data ... it would be
"fair" to delay some of the TCP data during it's bursts (like some video codecs
have when a high-entropy scene change occurs). That is because TCP
can afford to "wait a little longer" to get it's data across. The bursts 
are usually
bounded in time (a talkspurt, a scene change, etc.) ... and TCP can usually
afford to wait through these bursts. From the real-time application's 
perspective
they are being "good citizens" by not using bandwidth when they don't
need to (during VAD/silence or no video scene changes). Can't the TCP apps
step aside for a moment and acknowledge their good citizenship?

To be fair ... we really need to re-evaluate the issue of "fairness" 
capturing more
than just an INSTANTANEOUS BANDWIDTH ALLOCATION dimension. Is it "fair"
to slow down TCP more than present mechanisms allow? For a "insatiably greedy"
TCP connection the answer may be yes. For a TCP session with a reasonably
bounded amount of data the answer maybe no - because there is a linear
relationship with how long the data will take to get to the other side and
the slowdown rate.

This is a really tough problem.

Why this post? Simply because I'd desire each camp to widen their vision
of what is "fair/right/best" from their own myopic point of view. TCP'ers 
should
try to capture the spirit of Brian's comment ... that "forcing the problem
to fit [TCP's view of] a solution" is not appropriate. And that is, in 
fact, what
I perceive all the well-intentioned "TCP rate control" crowd to be doing here.

Please widen your perspective of the problem. Then comment. Don't expect
people like Brian to be happy with the "you must fit in to TCPs view of the
world" when most of their real-time applications are already being good
citizens (by not sending "all they can" when they don't have to). Do you
like being further punished because you weren't greedy when you could
have been?

Michael Ramalho

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 24 Nov 2003 12:06:45 -0500

My experience is that changing rate more than once is much more annoying
than
changing it several times.  

In our system, a percentage of errors is less annoying than a single rate
change.  Go over that percentage (which of course is somewhat variable
from human to human), and you would prefer to drop the rate.  YCMV
(C=codec).

Neither is "acceptable", in the sense of what you want to see, and what
you expect to see.  If that's the expectation we create for VoIP or
VideoOverIP, then we had better be prepared for disappointing usage
except in the case where free trumps quality.

I don't see why DCCP is of significant value to a real time, non interactive
stream.  Why is it better than UDP or TCP?  I think that TRFC
is still a killer that extra buffering won't fix.  

Brian

> From: David R. Oran [mailto:[email-masked]]
> Sent: Monday, November 24, 2003 10:34 AM
> To: Rosen, Brian; 'Magnus Westerlund'
> Cc: Phelan, Tom; [email-masked]'
> Been watching this thread. Throwing caution to the wind and 
> jumping in...
> 
> --On Monday, November 24, 2003 9:49 AM -0500 "Rosen, Brian" 
> <[email-masked]> wrote:
> 
> > 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.
> >
> 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?
> 
> > 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 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.
> 
> > 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?
> >
> 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.
> 
> > 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.
> I mostly agree with this.
> 
> > 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.
> 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
> > 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).
> >
> 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.
> 
> > 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.
> 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.
> 
> > 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.
> >
> 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.
> 
> > Brian
> >
> >
> >
> >> 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]
> >>
> >
> ------------------------
> 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: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 25 Nov 2003 12:52:13 +0100

Tom,

We do not just have to find ways to get some kind of "fairness"
between applications, but we actually have two main goals:
1) Avoid congestion
2) Improve network utilization

By probing the network, TCP strive for 2), and that is a good
think. When there is available bandwidth, it is a good thing
that this resource gets used for actual application data. 
However, sending data just to keep network resources degrades
goal 2). To me, this seems to be a tricky problem as TCP has
not at all been designed to interact with real-time streams.

/L-E

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Phelan, Tom
> Sent: den 20 november 2003 19:04
> To: [email-masked]'; Phelan, Tom; 'Rosen, Brian'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> 
> 
> Hi Phillipe,
> 
> The situation I'm worried about is a little different than 
> you describe. Say you have a 10M bps link, over which there's
> a 4M bps video stream and a long-lived TCP app.  The TCP app
> will take the remaining 6M bps, and then push for more,
> which might cause the video stream to lose packets.  The
> video stream then drops to 2M bps, and the TCP app expands to 
> 8M bps.  This hardly seems fair.
> 
> The video app can protect itself from this by transmitting 
> enough more than 4M bps to buffer itself against the TCP
> probes.  In this case we'd come to a relatively steady state
> where both apps are sending roughly 5M bps.  This seems
> reasonably fair to me, since the TCP app gets what it would
> get if it were competing with other TCP apps, and the video
> app gets to send at its full rate.
> 
> Tom P.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 25 Nov 2003 12:53:01 +0100

> DCCP is appropriate for RTP.

Unfortunately, I think this analysis is rather correct. If so, I 
wonder if it really makes sense to continue with the DCCP work,
if it can not solve the problem it is supposed to address. At
least we should slow down a bit and give it more time, hopefully
we can activate more people and get them involved in the work.

More specifically, I think it is totally wrong to postpone the
actual work as "future CC work" if DCCP with current CC's do not
solve the problems it was chartered to solve and claims to address.

/L-E

---

From: [email-masked]
Date: Tue, 25 Nov 2003 16:40:08 +0100

Lars-Erik,

I share your concern about "sending garbage" to "keep the pipe open".

I understand now that "probing" is required to achieve (2) in fairness to TCP
i.e. a traffic that is competing with TCP has to use the same "weapon".

My idea would be that if the TCP traffic is allowed to push the DCCP-born media traffic down in rate
I expect "probing" to be performed in order for the media traffic to discover that it can increase its rate,
**after a decrease**, if/when it can, i.e. when some/all of the TCP traffic is finished (which would be fair).

In short for media traffic via DCCP "probing" would be a continuous activity in order to push against
the TCP traffic,(the amount of pressure/resistance being tunable ?)

I am expecting a TCP-well-behaved media application to lower its rate (but not systematically by half ?)
if more TCP traffic happens and I also assume that all media applications should be
prepared/defined to either stop reducing their rate AND/OR cut off below a certain rate,
i.e. this should be tunable by marketing/policy/management.

I agree with Stephen that in all case probing means losses on both sides but
I expect error resiliency to cover that.

 I think that the sensible way to "probe" is to send "more media/packets" periodically (in bursts)
(instead of sending garbage as a shield of some sort).

In all cases I beleive the key is to understand the minimum rate of change of the data/packet rates
and minimum amplitude of the rate changes, the periodicty of the "probes" etc
that are required for maintaining a tunable level of "resistance" against TCP traffic.

So far it seems that only the "factor of 2" has been considered,
this may seem quite large (too large for a lot of apps and codecs)
and could make the future of DCCP pretty bleak.

Let me express my optimistic view as a metaphor:

To me it looks like the discussion has been a bit like discussing the usage of tires on cars and there would be 2 sides,
one that is against it and defends that raw steel is good enough (with FEC cushions on the seats !)
and the other extreme opinion that 2 meters thick balloon tires are what is required for good confort.

Could the truth be somewhere in the middle ?-)

Regards,

Philippe Gentric
Chief Architect
Philips Software

                                                                                                                                           
                                                       To:   "'Phelan, Tom'" <[email-masked]>                                        
                                                       cc:   "[email-masked]'" <[email-masked]>                                               
                                                        "[email-masked]'" <[email-masked]>                                                  
                                                        (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
               "Lars-Erik Jonsson (LU/EAB)"            Subject:    RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide                      
               <lars-erik.jonsson@ericsson.                                                                                                
               com>                                    Classification:                                                                     
                                                                                                                                           
               Sent by:                                                                                                                    
               [email-masked]                                                                                                          
                                                                                                                                           
               25/11/2003 12:52                                                                                                            

Tom,

/L-E

---

From: Stephen Casner <[email-masked]>
Date: Tue, 25 Nov 2003 12:39:40 -0800 (PST)

Replies to a couple of related messages, edited:

On Tue, 25 Nov 2003, Greg Herlein wrote:

> > Unfortunately filling the client buffer at a rate faster than
> > the media rate and "when you can" which introduces substancial
> > amounts of time (many seconds) of delay is a technique for
> > media distribution for which DCCP is not needed:
> >
> > It is called "progressive" download, it uses HTTP and it is deployed ...
>
> That's somewhat simplistic, really.  Progressive download has a
> similar effect but it's not controlled, and it's TCP only of
> course.

Yes.  More on the TCP point below.

> For unicast scenarios this kind of thing makes total sense if the
> source is non-real time (ie, streaming from disk).  It's not much
> more than an enhanced jitter buffer, really - you are just adding
> some extra buffer for times when the normal real-time flow is
> impaired, and a mechanism to allow the client to tell the source
> to "fill me up"  and "back it off."  There need not be any extra
> delay at startup, though not doing so creates a window of
> vulnerability.

Exactly right.  Thanks for saving me having to write this.

The point about no additional delay is important: the vulnerability at
startup is no worse than and in fact increasingly less than the
vulnerability for a stream sent constantly at rate 1.

> I'd very much like to see some standardization effort on a
> protocol to support this kind of thing - perhaps an RTCP
> extension?  Perhaps soemthing that can apply to TCP as well?

We talked about doing something like this in RTP itself a few times,
but deferred to congestion control work in other groups.  So DCCP is
now the proposed standardization effort.

On Tue, 25 Nov 2003, Rosen, Brian wrote:

> This would seem to only apply to a non-interactive stream, where
> several seconds of buffering is acceptable, correct?

Yes.

> You also, in this case, would not actually change the encoding
> rate, but merely change the instantaneous transmit rate.

Yes.  As I said earlier, you might use FEC to protect against the
probing initially here, same as you could use it to protect an RTP/UDP
stream, but once some buffer is built up for the non-interactive case,
then retransmission is more efficient.

> I'm not clear on how this is better than just using TCP.

The key difference is that TCP insists on 100% reliability.  It must
retransmit a lost packet before any subsequent data can be delivered.
For these media applications, retransmission may still be useful, but
you want the application to have control over the decision to
retransmit or to give up and continue on.

                                                        -- Steve

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:38:39 +0100

Brian, you wrote

>several seconds of buffering is acceptable, correct?

When you play with the transmit rate the larger the buffer/delay the easier ... .

And if you dont have delay then you really need to be able to change the media rate !

>rate, but merely change the instantaneous transmit rate.

in all cases when the temporary bandwidth reduction lasts longer than your buffer
...then you need to change the media rate, there is just no other way.

Actually for interactive (conferencing) case changing the rate
of the codec (media rate) is actually "easier" (in theory):
you just tell the codec(s) to produce less bits (!)
(it is "easier" in the sense that with pre-encoded media delivery you have to do stream switching instead)

>I'm not clear on how this is better than just using TCP.

If you only consider the case where the buffers/delays are really large
then yes, I tend to agree, (see other mail about progressive download)...

regards,

Philippe Gentric
Chief Architect
Philips Software

---

From: "Qiong Li" <[email-masked]>
Date: Wed, 26 Nov 2003 10:18:04 -0500

Hi Everyone,

Here is some of my thought related to this topic.

It may be arguable whether layered audio and video are needed for wired
sections of the Internet, However, it seems that scalable coded media
contents may still be necessary for wireless delivery, especially in
mobile environments, or in cases where the end-to-end paths have
wireless link segments. The bandwidth variations on wireless links could
be due to completely different reasons from congestion, such as fading,
interference, mobility, etc.

It seems that when wireless link degradation happens, there are no known
QoS mechanisms that can still provide previously negotiated services. To
deal with this problem, many research works proposed to deploy so-called
soft QoS in which service quality can vary in a range, or to encourage
application repeatedly renegotiate a different QoS level with the
network. Once any of these happens, adaptation on content bit rate seems
unavoidable.

Also from a user perspective (I don't have experiments to support this),
assuming the case where a person who listens to music (may be companied
with low bit rate video). He may from time to time experience the
degradation of sound and picture qualities whenever he walks under a
construction or enter a new cellar domain, etc. this degradation would
be understandable and acceptable to the user. However, if the sound
completely stopped and the picture frozen, he would have no clue whether
this problem is because he just got a broken phone or else.

Therefore, if the digitized media can be delivered as resilient as
analog format, that may be the direction we want to pursue.

Of course, layered media contents are not necessary to be delivered by
DCCP-like protocols.

Thanks,
-qiong
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen,
Brian
Sent: Monday, November 24, 2003 9:49 AM
To: 'Magnus Westerlund'
Cc: Phelan, Tom; [email-masked]'
Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide

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.

recommendation of dropping the flow if excessive packet loss is observed

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

> sharing you view due to the implications that your claims results in.
> 
> IP network, i.e. without any QoS guarantees across the whole net that 
> quality to often, however there are reasons for switching up when the 
> are not, the combination of several of media application can totally

---

From: [email-masked]
Date: Wed, 26 Nov 2003 17:30:54 +0100

Henning, TFRC experts,

>> It would be interesting to look at the voice response to changing
>> packetization period.

...

>
>We have looked at this systematically, varying the packetization
>threshold. See the papers by Wenyu Jiang and myself at
>http://netbib.info and http://www1.cs.columbia.edu/~wenyu/
>

Does anyone have a clue of how changing the packetization
impacts the behavior of TFRC in presence of TCP traffic ?

For example if an application increases its packet rate
(same media rate, higher transmit rate due to packet headers contribution increasing)
is that added "pressure" against competing TCP traffic ?

regards,

Philippe Gentric
Chief Architect
Philips Software

---

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 26 Nov 2003 11:48:21 -0500

Hi Phillipe,

TFRC is packet rate based, not bit rate.  If TFRC cut your allowed packet
rate in half, it'd be OK (at least as far as TFRC is concerned) if you cut
your packet rate in half, but doubled the packet size.  Of course in many
circumstances this action would be unlikely to alleviate the network
congestion, and some of these new big packets would probably be lost,
causing TFRC to cut the allowed rate even more.

TCP, on the other hand, is bit (or byte) rate based.  Network congestion is
both bit and packet rate based (others things too, I suppose), although I
think the packet rate problems are diminishing (Moore's law helping us
there).

If going to smaller packets gets you a higher bits-on-the-wire rate, then
you'd get some of the buffering I was talking about.  On the other hand, if
the chokepoint was packet-limited rather than bit-limited ...

Tom Phelan

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Wednesday, November 26, 2003 11:31 AM
> To: Henning Schulzrinne
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide
> 
> 
> 
> Henning, TFRC experts,
> 
> 
> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
>

---

From: [email-masked]
Date: Wed, 26 Nov 2003 18:49:39 +0100

Tom, you wrote:

>There have been a lot of comments on this
>thread about the difficulties in the human perception of rate-shifting, and,
>in general, I'd have to say the comments are pretty accurate, especially
>given the current state of the art in codec design.

Recent/hi-end digital TV (mpeg-2) codecs change their rate *all the time*.
They do that  to assign different bit rates to different channels based on the program/time
(you put more bit rate on channel 12 when the movie or baseball match starts)
and/or based on statistical multiplexing (i.e. the rate change several times per picture).
This is deployed all over the face of the planet.
Of course if you change from 4 Mb/s to 1 Mb/s the users may see the difference,
but less drastic changes are hardly noticed but by experts (did you notice it ?) ...

My group has products that dynamically change the rate of (MPEG-4) video
(even down to very low bit rates e.g. the GPRS range at 20 to 50 kb/s)
We do the same for speech in the 5-24 kb/s range.
(BTW: AMR stands for Adaptive Multi Rate !)

So I am really surprised with all this negative feedback about codecs
and this notion that it is impossible/bad to change rates ?

regards,

Philippe Gentric
Chief Architect
Philips Software

---

From: [email-masked]
Date: Wed, 26 Nov 2003 18:57:52 +0100

Stephen, you wrote:

>One quick point, relating back to the start of the thread:  If you are
>competing with one or more TCP streams and the total traffic is
>filling the available bottleneck bandwidth, then if you back off the
>video rate as a result of the loss induced by TCP rate probing, the
>TCP streams will expand to fill the bandwidth you freed and then probe
>for more until you stop.

right, so it proves the need for "probing" (in the limit allowed by TFRC of course ;-)
i.e. the media stream must "put some pressure" on the TCP traffic.

Now when you try to find out how to do that you find the following possibilities:

* increase the instantaneous transmit rate = works only within buffers/delay limits

* increase the instantaneous media rate = works always (assuming the right codecs)

regards,

Philippe Gentric
Chief Architect
Philips Software

                                                                                                                                       
                                                   To:   "Rosen, Brian" <[email-masked]>                                      
                                                   cc:   AVT WG <[email-masked]>                                                         
                                                    [email-masked]                                                                      
                                                    (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                         
               Stephen Casner                      Subject:    [AVT] RE: [dccp] Re: DCCP Media Guide                                   
               <[email-masked]>                                                                                                        
                                                   Classification:                                                                     
               Sent by:                                                                                                                
               [email-masked]                                                                                                      
                                                                                                                                       
               26/11/2003 18:35                                                                                                        

On Wed, 26 Nov 2003, Rosen, Brian wrote:

> Again, I think the most acceptable response to congestion for
> video is to rate shift down once, or if necessary, twice to
> get to an "acceptable" level of errors.  So, it's not freeze
> frame vs rapid rate shift, it's rate shift down vs rapid rate shift.
>
> We have a different error result than freeze, and it seems to work
> better (less objectionable), but it doesn't change the equation.
> If you get too many errors, you lower the rate until you don't
> get "too many".

One quick point, relating back to the start of the thread:  If you are
competing with one or more TCP streams and the total traffic is
filling the available bottleneck bandwidth, then if you back off the
video rate as a result of the loss induced by TCP rate probing, the
TCP streams will expand to fill the bandwidth you freed and then probe
for more until you stop.

                                                        -- Steve

---

From: [email-masked]
Date: Wed, 26 Nov 2003 19:17:27 +0100

greg you wrote:

>> I fully agree this is the fundamental reason why another
>> protocol than TCP is a good idea: media does not need 100%
>> reliability.
>
>I don't agree.  *Some* media does not need 100% reliability.
>But many video codecs have pathetic performance in the face of
>packet loss - and FEC is not always a good solution

the bad news is probably  that if you have to use such codecs then DCCP is not for you ?

BTW the more recent/advanced codecs have error resilience features designed-in for that reason:
people were horrified when they found out how the lack of resistance to even a small error rate
was generating additional cost in deployments e.g. in DTV  the additional bandwidth cost of the required FEC
plus bill-of-material cost of FEC decoders on the STB is quite substancial...

regards,

Philippe Gentric
Chief Architect
Philips Software

---

From: John Lazzaro <[email-masked]>
Date: Wed, 26 Nov 2003 12:15:26 -0800 (PST)

> [email-masked] writes:
>
> The other idea I have been trying to advocate for a while because I
> believe it i s another key to the problem is that media does not need
> to be constant bit rate, nor constant packet rate, n or constant
> packet size.

As an existence proof, RTP MIDI is potentially non-constant in all of
these ways.  And, with the appropriate choice of renderer, the RTP
MIDI stream could be just as normative a codec as AAC -- the SDP
machinery in Appendix C.5 of the RTP MIDI format I-D is designed to
support this.

This was Eric's motivation for doing Structured Audio, and my original
motivation for writing an SA compiler (although the emphasis switched
to network musical performance a few years into the project ...).

---------------------------------------------------
John Lazzaro    http://www.cs.berkeley.edu/~lazzaro
     lazzaro [at] cs [dot] berkeley [dot] edu     
---------------------------------------------------

---

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 26 Nov 2003 11:48:21 -0500

Hi Phillipe,

Tom Phelan

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Nov 2003 09:26:03 -0500

It would be interesting to look at the voice response to changing
packetization period.  Clearly, the effect of the loss of one large
packet is worse than the effect of a small packet.  Small packets have
more bit rate, so, you would presumably be sending larger packets
when you have congestion.  What does that do to the perceived quality?
It's going to get worse as congestion gets worse, which in some sense
is "good", but is it actually worse than a higher packet loss rate,
but less problem for each loss?  Probably depends on the loss pattern.
If it were random, than the smaller problem, larger percentage is
probably better, but it's not random.

There are people who know a lot about such things.  I'm not one of them.
Do we have some of that expertise around on the list?  Has that idea
been tried?

I do think we need to split this thread, or at least mark replies with
"Applies to interactive real time" vs "applies to non-interactive real
time".
I appreciate several comments on the thread that DCCP may have more
applicability to non-interactive streams.  While many of the effects
are similar (rate shift to non-interactive is just as objectionable
to non-interactive as it is to interactive), some things are clearly
different (slow start, for example).

Brian

> Sent: Wednesday, November 26, 2003 8:25 AM
> To: [email-masked]'
> Subject: RE: [dccp] Re: DCCP Media Guide
> 
> 
> Hi Phillipe,
> 
> [snipped]
> > The other idea I have been trying to advocate for a while 
> > because I believe it is another key to the problem
> > is that media does not need to be constant bit rate, nor 
> > constant packet rate, nor constant packet size.
> 
> I'm glad you brought this up.  There have been a lot of 
> comments on this
> given the current state of the art in codec design.  However, 
> I can think of
> at least two instances where rate shifting is either workable 
> or better than
> the current practice.
> 
> One case involves audio codecs such as G.711 and changing the 
> packetization
> interval.  G.711 with 10ms packetization is about 96K IP bps 
> on the wire.
> 40ms packetization gives about 72K bps.  I think that 
> changing between these
> two rates is often close to imperceptible.  A similar thing 
> can be done with
> G.729A (although I'm not sure the standard allows it), giving 
> more variation
> in the bit rate - 10ms packetization is about 38.4K bps and 
> 40ms is 14.4K.
> 
> Another case involves video transmission.  As you change 
> between a high and
> low encoding rate the image the user sees is likely to change 
> back and forth
> between clear and grainy, and this is likely to be annoying.  
> But I imagine
> it's less annoying than the current practice of freezing the 
> video (and
> continuing the audio) when there's insufficient bandwidth for 
> the high-res
> video.  I imagine that layered encoding techniques like 
> Gerard Babonneua
> mentioned can fit this mode of operation nicely.
> 
> Given that there are these low-hanging-fruit stream shifting 
> methods, I
> wonder what others are available if we put our minds to it?
> 
> Tom Phelan
> 
> > These 3 things (delay, reliability, variable rate/packaging) 
> > should give some slack
> > for the design of a solution with added value no?
> > 
> > regards,
> > 
> > 
> > Philippe Gentric
> > Chief Architect
> > Philips Software

---

From: BABONNEAU Gérard FTRD/DMI/REN <[email-masked]>
Date: Fri, 28 Nov 2003 12:12:15 +0100

Hello Tom,

I think it is important to highlight the lack of performances of most codecs to a few losses in a network. Today, without losses, hierarchicals codecs give a little bit less quality than state of the art as MPEG4-AVC. Works are in progress to obtain the same quality with multilayers codecs than monolayer (ie: MPEG SVC, MPEG-21 Part 13). Hierarchical codecs allow an easy differentiation of data in network and in transport layer, and they can help in the objective that a minimum of data reach the decoder for a minimal quality, instead of nothing or something out of tune.

Best regards,

Gérard

-----Message d'origine-----
De : Phelan, Tom [mailto:[email-masked]] 
Envoyé : mercredi 26 novembre 2003 14:25
À : [email-masked]'
Cc : [email-masked]; [email-masked]
Objet : [AVT] RE: [dccp] Re: DCCP Media Guide

Hi Phillipe,

[snipped]
> believe it is another key to the problem is that media does not need 
> to be constant bit rate, nor constant packet rate, nor constant packet 
> size.

I'm glad you brought this up.  There have been a lot of comments on this thread about the difficulties in the human perception of rate-shifting, and, in general, I'd have to say the comments are pretty accurate, especially given the current state of the art in codec design.  However, I can think of at least two instances where rate shifting is either workable or better than the current practice.

One case involves audio codecs such as G.711 and changing the packetization interval.  G.711 with 10ms packetization is about 96K IP bps on the wire. 40ms packetization gives about 72K bps.  I think that changing between these two rates is often close to imperceptible.  A similar thing can be done with G.729A (although I'm not sure the standard allows it), giving more variation in the bit rate - 10ms packetization is about 38.4K bps and 40ms is 14.4K.

Another case involves video transmission.  As you change between a high and low encoding rate the image the user sees is likely to change back and forth between clear and grainy, and this is likely to be annoying.  But I imagine it's less annoying than the current practice of freezing the video (and continuing the audio) when there's insufficient bandwidth for the high-res video.  I imagine that layered encoding techniques like Gerard Babonneua mentioned can fit this mode of operation nicely.

Given that there are these low-hanging-fruit stream shifting methods, I wonder what others are available if we put our minds to it?

Tom Phelan

> These 3 things (delay, reliability, variable rate/packaging) should 
> give some slack for the design of a solution with added value no?
> 
> regards,
> 
> 
> Philippe Gentric
> Chief Architect
> Philips Software