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
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

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