Subject: RE: [Tsvwg] Re: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide

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

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

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

---

From: "Phelan, Tom" <[email-masked]>
Date: Fri, 21 Nov 2003 13:26:49 -0500

Hi Caitlin,

See inline ...

Tom Phelan

[snipped]
> 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 don't think TFRC in and of itself is unfriendly - it depends on how you
use it.  If you employ strategy 3 from the draft, then you could be subject
to undesirable effects while competing with other TCP (or TFRC) apps.
Strategy 3 bis tries to correct these problems.

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

Nothing in the draft declares itself exempt from TFRC - all strategies are
bound by TFRC.  At no time do you transmit faster than TFRC will allow.
Sometimes you might transmit slower.

> 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 don't know whether our current two choices for flow control mechanisms
(AIMD, as in TCP, or TFRC) are enough or not.  Maybe they are; maybe we need
one or two more.  Regardless, each application that uses one of these
mechanisms must decide how.  For some apps it will be simple - always
transmit as fast as the flow control allows.  For other apps (streaming
media being the current topic), it's more complicated.

My purpose in the DCCP Media Guide was to ask the question, "Can streaming
media apps use TFRC successfully?"  Personally, I don't think it answers
that question.  I hope it does illuminate some of the issues, though.

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

I don't see why an alternate to TFRC needs to accommodate all other
connection-oriented traffic.  If we come up with a third congestion control
mechanism that satisfies the needs of some set of applications while
maintaining "fairness" with TCP and TFRC, that seems OK.

That isn't to say that I think we need a third mechanism.