Subject: RE: New congestion control text in RTP spec

From: Markus Buchhorn <[email-masked]>
Date: Fri, 01 Sep 2000 10:43:35 +1100

At 17:54 31/08/00 -0400, Doug Sauder made some good points:

>My comment is that I think a real paradigm shift is necessary when
>considering congestion control in RTP. 
[...]
>So, what I think this really comes down to is -- as another in this thread
>has pointed out -- that it all has to do with diffserve, policing, and so
>on. 

Agreed. But I'm not sure if that is a paradigm shift, or simply finally
using the TOS byte in an intelligent fashion. Ultimately it comes down to
which layer should handle traffic management and which should handle
application management. A similar argument came up in multicast-addressing
schemes for high-bandwidth streams in Internet2-like environments (do you
allocate an address block, just so you can block some high-bandwidth
sessions from hitting narrow-band links? Or to stop users requesting a
stream they can never fully receive?).

> I think it's been an implicit assumption throughout most of this
>discussion that most RTP traffic should be labeled with a high priority in
>almost all cases.  [...]
> On the other hand, someone else mentioned receiving streaming audio via
HTTP.  So,
>priority can't be inferred by transport protocol alone. 

streaming and http just shouldn't be in the same sentence. Just as non
"real-time" traffic that is multicast shouldn't be run over RTP (e.g.
digital fountains, bulk data transfers, etc.). http is way overloaded
because it beats many firewalls, and the client is cheap. 

>Finally, considering that the Internet is such big business nowadays, won't
>this congestion "problem" just be taken care of by free market economics?

I agree that ultimately on the commercial Internet it is the *end-user* who
should decide their priorities (and abilities), probably on an
application-by-application basis. Make it extremely dynamic if at all
possible. Is this RTP stream a live video-conference/interactive surgery or
some streamed content that can handle many seconds of buffering? Same as on
TCP, is it an ftp session from Microsoft Updates, or my Doctor upgrading my
pacemaker firmware over the network? :-) Looks the same to the network (but
are hopefully NOT equally likely to kill me ;-) ).

I will know far more about what I'm running than my ISP (unless we have a
distinct protocol tag for *every* type of application), and how I want it
handled - and I can decide how much I'm prepared to pay at the time.

Let the users decide - they are the ultimate "intelligent" edge of the
network after all. Then bill them accordingly. Packet Democracy or
Capitalism - pick one :-)

Cheers,
	Markus

PS I haven't got a pacemaker, for any concerned souls out there.

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: [email-masked], snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429

---

From: "Doug Sauder" <[email-masked]>
Date: Thu, 31 Aug 2000 17:54:47 -0400

REM-CONF members,

I think I have read all of this thread now.

My comment is that I think a real paradigm shift is necessary when
considering congestion control in RTP.  The congestion control for TCP
originates from a different era.  The conditions have changed drastically
since then.  First, and foremost, you won't find the kind of "be nice, be
fair" attitude that prevailed before about 1995.  The Internet today is big
business. Individuals and companies pay for Internet service, and they want
to get nothing less than what they paid for.

So, what I think this really comes down to is -- as another in this thread
has pointed out -- that it all has to do with diffserve, policing, and so
on.  I think it's been an implicit assumption throughout most of this
discussion that most RTP traffic should be labeled with a high priority in
almost all cases.  I know that when I am listening to streaming audio, I
don't want to see the quality decline when I decide to check my email at the
POP server, especially if the agreement I have with my ISP should allow for
both to happen at the same time (a DSL connection, for example).  On the
other hand, someone else mentioned receiving streaming audio via HTTP.  So,
priority can't be inferred by transport protocol alone.  But, to get back to
my point, *any* congestion control for RTP that does not take into
consideration some kind of differentiated services it overly simplistic.

Maybe UDP should only "compete" with UDP.  That would be simple to police: X
amount of bandwith must be allowed for UDP, Y amount bandwith must be
allowed for TCP, and Z amount of bandwith can be allowed for either.  In
other words, there would be a minimum (guaranteed) and maximum bandwidth for
UDP (and therefore RTP).

To take these comments in a slightly different direction, I question the
need for congestion control.  I get the impression (which might be a wrong
impression) that the real limiting factor in the use of the Internet is most
likely going to be at the very edge of the network.  Content providers are
limited by the capacity of their servers.  Home users and small businesses
are limited by their connection speeds.

Finally, considering that the Internet is such big business nowadays, won't
this congestion "problem" just be taken care of by free market economics?
Suppose a large company wants VPN service from a large ISP, and that that
large company wants voice and data convergence.  (They'll be using RTP to
carry all the telephone traffic between their offices around the world.)
This sounds to me like it's more a problem of traffic engineering than a
problem of congestion control.  And the ISP has great incentive to solve it.

Doug Sauder
Software Engineer
BroadSoft, Inc

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Tuesday, August 15, 2000 12:56
> To: [email-masked]
> Subject: Re: New congestion control text in RTP spec
>
>
> > What I was trying to imply in my text suggestion is that one should try
> > to specify a congestion control behavior that takes the applications
> > needs as well as the networks state in consideration and not merely the
> > network state (loss and delay) as is currently the case for most
> > congestion control schemes (and certainly for TCP) or the applications
> > needs as Thomas was suggesting
> >
> > Such a control behavior should on the one hand lead to a smooth
> > perceived QoS and should not result in starving competing flows.
>
> the IESG will look very hard at any proposal that does not protect
> the network from congestive collapse and do so in a way that does not
> unfairly harm the other traffic on the network
>
> Scott
>
>