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

From: BABONNEAU Gérard FTRD/DMI/REN <[email-masked]>
Date: Fri, 21 Nov 2003 16:53:37 +0100

I had a carefull look at the draft.
In my opinion, coding with two or more rates is only TCP compliant, and it does'nt improve the video quality because the network losses have disastrous effects (30% pictures loss for 3% packet loss). We (France Telecom R&D) have developped a test bed with MPEG4/RTP/UDP hierarchical codec with 2 or more layers for the video. A DSCP marking allows diffserv routers to choose packets to be lost when a congestion occurs. We have a better quality than other codecs in a lossy environment and it also works in multicast sessions. Diffserv routers can also share the bandwidth between UDP and TCP flows, to guarantee a good throughput for all the flows on the network. 

Gérard BABONNEAU

-----Message d'origine-----
De : Rosen, Brian [mailto:[email-masked]] 
Envoyé : jeudi 20 novembre 2003 19:24
À : 'Phelan, Tom'
Cc : [email-masked]'; [email-masked]'
Objet : RE: [AVT] RE: [MMUSIC] DCCP Media Guide

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

> -----Original Message-----
> From: Phelan, Tom [mailto:[email-masked]]
> Sent: Thursday, November 20, 2003 11:48 AM
> To: 'Rosen, Brian'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> 
> 
> Hi Brian,
> 
> Thanks for the comments.  See inline ...
> 
> Tom P.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Thursday, November 20, 2003 11:05 AM
> > To: 'Phelan, Tom'; 'Jonathan Rosenberg'
> > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> > 
> > 
> > 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.
> 
> 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.
> 
> > 
> > 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
> 

_______________________________________________
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: "Vinay Sathe" <[email-masked]>
Date: Sun, 23 Nov 2003 06:11:50 -0800

Hello Gerard
Your results sound very interesting. Is there a reference/ web site you can
quote to read more about your work? 
Thank you,
Vinay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BABONNEAU
Gérard FTRD/DMI/REN
Sent: Friday, November 21, 2003 7:54 AM
To: Rosen, Brian; Phelan, Tom
Cc: [email-masked]; [email-masked]
Subject: RE : [AVT] RE: [MMUSIC] DCCP Media Guide

I had a carefull look at the draft.
In my opinion, coding with two or more rates is only TCP compliant, and it
does'nt improve the video quality because the network losses have disastrous
effects (30% pictures loss for 3% packet loss). We (France Telecom R&D) have
developped a test bed with MPEG4/RTP/UDP hierarchical codec with 2 or more
layers for the video. A DSCP marking allows diffserv routers to choose
packets to be lost when a congestion occurs. We have a better quality than
other codecs in a lossy environment and it also works in multicast sessions.
Diffserv routers can also share the bandwidth between UDP and TCP flows, to
guarantee a good throughput for all the flows on the network. 

Gérard BABONNEAU