Subject: Re: New congestion control text in RTP spec

From: Scott Bradner <[email-masked]>
Date: Tue, 15 Aug 2000 12:56:29 -0400 (EDT)

> 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

---

From: [email-masked]
Date: Wed, 23 Aug 2000 14:15:21 -0500

> -----Original Message-----
> From: EXT Madan A S [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2000 3:03 AM
> To: [email-masked]; [email-masked]
> Subject: Re: New congestion control text in RTP spec
> 
> 
> > With RTP on the other hand, it seems the load generated by each
> transmitter
> > is constant, and does not increase when pakcet loss or network delay
> > increases.
> > This is not entirely true when packet retransmission is 
> added, but as long
> > as this is true, i.e. there is a definitive upper limit on the load
> generated by
> > each particular client, there might be no need for an additional
> congestion control
> > mechanism, becasue with such an upper limit RTP will not cause a
> congestion collapse.
> >
> 
> Would somebody mind explaining me,
> Why the load generation from transmitter is CONSTANT in case of RTP ?

No, it isn't. For voice, a codec without silence suppression may generate
constant RTP payload. However, if the silence suppression is turned on, 
there will be no RTP packets generated during the silent periods, except
for some small packet carrying comfort noise information (if the CNG is
switched on also). 

As to video, you probably all know it's VBR in nature. The load won't be
constant unless you do some buffering. But this is probably not tolerable
for real-time video. RTP stands for real-time, anyway.

I didn't follow this thread continuously (I'm currently busy with RTP
header compression in rohc WG). So I'm not sure what kind of congestion
control you guys are talking about. To me, it looks like a more general
problem of QoS (admission control, policing, blah, blah), which is not
specific to RTP. The picture in my mind is a big (perhaps not big in some
cases) IP pipe which carries all kinds of IP flows (TCP, UDP, etc). 
Congestion control can be only effective if all flows conform to some
rules. (e.g. TCP is a little bit aggressive here). Again, I'm just
waving my hands.

Br,
Zhigang

---

From: John Lazzaro <[email-masked]>
Date: Thu, 24 Aug 2000 13:07:57 -0700

[ Thomas Marshall Eubanks <[email-masked]> writes ]

> By aggressive we meant that a RTP stream should not back off every time it
> losses a few packets. In broadcasting, a human requests a RTP  video or
> audio stream - it should be possible to get good reception and still
> surf the web or do downloads. If it is not, the customer will not use the
> service !

But should TCP users of the affected shared links be at
the mercy of Joe Sixpack's decision to shut off the IP-radio/TV?
Once its clear to a unicast source that its receiver is
getting unusable reception quality for significant periods of
time, some sort of automatic congestion control seems in
order (conceptually, a low-bandwidth "please stand by" screen,
if you will, followed by a "disconnecting, please try later"
message if things don't improve), rather than waiting for a
human to give up on using a receiver application. I remember
trying to get work done on the net during the first "Victoria's
Secret" fashion show a few years ago, and it was pretty slow
going -- on that day, at least, Joe Sixpack didn't seem to
be turning off the IP-TV and giving up very quickly!

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 24 Aug 2000 16:39:36 -0500

> You should not confuse "real time" with the end-to-end delay issue.
> small E2E delay is a very strong requirement for videophony
> *only*, video broadcast (or even VOD) with several seconds of 
> delay is quite OK.

Well, I thought "real time" IS about "end-to-end" delay. But,
maybe "real time" has a different meaning here (e.g. live)?
I perfectly understand that video broadcast or streaming can
tolerate some E2E delay. But I'm wondering if several seconds
of delay can be still called "real time". Again, I'm now
totally confused about the terminology of "real time"?

...
(this part is omitted which I Agree)
...

> *however* codecs can *also* be used with "more" rate control,
> and then you will get constant BR, with potentially
> large delays to compensate (buffering) instantaneous
> BR variations ....

Yes. If the buffer is considered part of the codec, then you
can always smooth out the bit rate, with the cost of longer
delay.
 
...
(cut many lines here about multiplexing)
...

Statistical multiplexing is one of the fundamental
ideas for Internet. (e.g. Ethernet LAN, IP core network). 

> > rules. (e.g. TCP is a little bit aggressive here).
> 
> 
> 
> what do you mean by aggressive ?
> It is my understanding that if a UDP and TCP flow
> "fight" for bandwidth the TCP congestion control will
> cause the UDP stream to "win" ? does not sound
> like aggressive to me ?

By aggressive I mean TCP tries to take whatever it can. But
on the other hand, you're right. It's also polite by reducing
sliding window if the bandwidth is taken by other streams.
 
> Isn't the issue that once all TCP flow are reduced to the min
> UDP (RTP actually) flows should start to behave and reduce BR too ?

Yes, it is. As I said, it looks more like a QoS issue.

> you mean you want to make sure TCP gets a "fair" share too,
> how would "fair" be defined ?

Good question. Again, fairness a QoS issue, which is quite complicated.
I'm not sure here is the right place to discuss it. But, the basic
idea is that each IP flow (either UPD or TCP or whatever) will contract 
some QoS (e.g. average and peak throughput, maximum delay, etc.). Then
some entity(ies) has to make sure each flow obeys the contract. 

But again, congestion control discussed here may be a different thing.
It looks like voluntary self-control based on some guessing of network
condition, not based on some QoS contract. Besides, is the congestion
control per-flow based, or per protocol based (e.g. UDP or TCP), or 
aggregate (i.e. all IP flows from one node)?

Zhigang