Subject: [Tsvwg] RE: [dccp] DCCP Media Guide

From: "Phelan, Tom" <[email-masked]>
Date: Fri, 21 Nov 2003 09:01:54 -0500

Hi Qiaobing [trimmed list a bit],

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

The current practice for streaming media is unfair to TCP (well, at least
according to the IAB, an opinion that I buy into).  If we modify the
behavior of streaming media so that it is fair to TCP, we must also be
certain that TCP is fair to this new behavior.  This bi-directional fairness
doesn't seem to have gotten much attention yet.

> I am not convinced this is the right thing to do with DCCP.

I'd love to hear opinions on this.  But if DCCP doesn't give acceptable
service for streaming media, then it isn't going to be used for streaming
media.

Tom Phelan

> 
> 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.
> 
> regards,
> -Qiaobing
> 
> "Phelan, Tom" wrote:
> 
> > 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.
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]
> > > Sent: Thursday, November 20, 2003 12:23 PM
> > > To: Phelan, Tom; 'Rosen, Brian'
> > > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> > >
> > >
> > > 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,
> > >
> > > 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
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> > >
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > 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
> 

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 21 Nov 2003 10:57:51 -0600

> service for streaming media, then it isn't going to be used for 

Two very good observations.

But they lead to some very crucial questions:

Is "TCP Friendly Rate Control" unfriendly to an entire class of 
applications?

	I believe that is the case. If so, a solution that is wider that an
	application protocol is called for. If not so, then that application
	should conform to TCP Friendly Rate Control rather than just declaring
	itself to be exempt.

Is it possible to build a two-pronged rate control solution?

	My understanding of the position of those that advocate TCP Friendly
	Rate Control alone is that they do not believe a two-pronged approach
	is plausible.

	I am not certain. What I am in agreement on is that it should
	not be 'n-pronged' where every application that thinks that
	TCP friendly rate control is unfair to it simply exempts
	itself and creates its own *separate* flow control.

	I am a firm believer that *all* applications share the same
	fundamental assumption about network congestion -- namely that
	it is a problem caused by *other* applications.

	If there is to be an alternate to TFRC, it must accommodate
	virtually *all* other connection-oriented traffic. Otherwise
	each little turf will "solve" the network congestion problem
	based upon the above cited universal assumption.