Subject: Re: New congestion control text in RTP spec

From: [email-masked]
Date: Thu, 24 Aug 2000 12:09:53 +0200

[email-masked] wrote:

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

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.

"> Why the load generation from transmitter is CONSTANT in case of RTP ?"

Well that depends, both cases are possible.

Actually there is a continuum of possible rate variations,
also "constant bit rate" is even tricky to define
with codecs that support variable frame rates (MPEG-4),
actually you can define it only
with the addition of the end to end delay
parameter and probably the buffer sizes.

It is true that video codecs can be run in a "constant quality"
mode and then potentially *extremely large* bit rate variations are possible,

and actually desirable.

Specifically a camera monitoring a lobby
would send almost nothing when the lobby is empty.

Note that this kind of extremely static and
long scenes is pretty rare in
TV or Cinema content, because viewers have
a strong tendency to get bored very fast :-)

However this kind of thing is done for storage,
for image quality optimization
for exemple video CDROM (MPEG-1)
and DVD (MPEG-2) are done somewhat in that way,
with bit rate boundaries due to disk reader
technology and MPEG standard (decoder buffer size).

Note that the video codec of MPEG-4
offers more flexibility (non constant video frame rate,
wider decoder buffer size range) and therefore can
produce better quality using VBR mode, with potentially
quite large "intantaneous" bit rate changes
(specifically encoded frame size change, but also
the frame rate can be reduced).

So direct usage of this kind of content for VOD
services would produce VBR videos.

Also applying the same "best quality" encoding
for broadcast would produce VBR videos.

So you can expect that some RTP video will
have variable "instantaneous" bit rates,
because this is how you get better quality.

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

*********************

Furtheremore for digital TV broadcast statistical multiplexing
is in use rigth now i.e. a set of real time video encoders
are synchronized so that the sum of all BR is constant
to fit the pipe size while individual BR change constantly
according to an algorithm that tries to optimize quality
for each stream. For exemple the NBC channel
broadcast a basket match will get more BR,
while ABC will get less because at the same time
it is broadcasting a Goddard movie with very long
very static scenes ...

In that case you may get wide (and rapid too) BR changes
for all streams ... with a constant sum !

This is what the broadcaster may want on the Internet too:
assuming "they" are paying the *total* bandwidth,
they will want to maximize quality
at all cost inside that enveloppe.

Although this could be done with a varying sum,
which would be driven by some congestion control,
but does the work discussed here cover that ?

***************************

Also the business model is unclear to me

- for broadcast (say using IP multicast)
i.e. what would be the exact motivation
of a broadcaster to reduce the BR
(and therefore the quality) ?
Because a certain number of  users report
congestion problems ?

- for pay per view VOD, once the user has paid,
it would difficult to reduce the BR and explain
that he (she) is getting crappy quality because
of congestion ?

comments anybody ?

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

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 ?

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 ?

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

Regards,

--
Philippe Gentric
Software Architect
PHILIPS DIGITAL NETWORKS
Broadcast & Internet Delivery Solutions
Laboratoires d'Electronique Philips
B.P. 15 - 22, Av. Descartes
94453 Limeil-Brevannes Cedex France
Phone  :   33 (0)1 45 10 68 12
Fax    :   33 (0)1 45 10 69 60
[email-masked]

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Thu, 24 Aug 2000 10:08:35 -0400

Dear Philippe;

   We have been sloppy in our use of terms such as "constant load".

[email-masked] wrote:

> >'

There is the rate being generated by the source, and the rate being pushed
across
the network. Even if the rate from the source is constant, in TCP slow
start and congestion control will cause a constantly varying load.
In a download type situation TCP will expand to fill whatever bandwidth is
available.
If there are multiple TCP download type sessions going on, then in a double
average sense (both an ensemble average and an average over time), each
session would get roughly 1/N of the available end to end bandwidth.
This discussion started because the draft profile suggested (to me, at any
rate),
that a TCP like congestion control be the ideal for RTP/UDP sessions.
This is not a good idea for the typical audio or video stream scenario. A RTP
stream with layering can be reduced, but never increased above a certain level,
while TCP file transfers  can.

In the absence of congestion, for a multicast RTP/UDP audio or video session,
there
is a roughly constant bit rate. (Yes, audio has constant bit rate and variable
bit rate, and video can get even more complicated, but we are talking about the
response to congestion and network conditions here - presumably
the congestion does not depend on what is being broadcast !) The point simply
is that if there were no other TCP or UDP traffic
the RTP stream would use a certain number
of bits per second on average; it wouldn't grow to fill the entire available
bandwidth.
In multicasting (if done right) every node in the network with a multicast
stream would
see the same (possible time variable) bit rate, call it r(t)
In unicasting, for a given group size N, every node participating would see a
bit rate
from the stream of at most N times r(t)
and at least r(t). Now, Leonid is right in that, if N is a constant, so is the
flow at a
given node (ignoring variations in r(t)), but in most real world broadcasts N is
not
constant, so that the flow rate will change in  unicasting, while
in multicasting it is always either 1 or 0 times r(t). (Of course, all
methods also have small control packets flowing back and forth, such as
RTCP packets; generally the bit rates of these are small enough to ignored. In
default rtp/rtcp, the real flow is about 1.05 x r(t), for example.)

So, you could say loosely that RTP multicasts with no congestion control
cause a "constant load" - what you really mean is that the load attempted is
just
r(t), independent of network conditions.

<snip a lot I agree with>

Not in my opinion. This might work at the sender, but how
could it work at the other end? Suppose Indiana watches
the basketball game, but New York chooses to fall asleep during the
Goddard movie - how does this even out ?

I would argue that broadcasters would basically
never reduce their bit rate on the commodity Internet, at least not
in any dynamic fashion (neglecting VBR changes due to changing
content).

In large scale multicasts on the commodity Internet, someone will always be
in trouble (i.e., dropping packets) SOMEWHERE. So, if the audience is large,
having the broadcaster reduce the bit rate in case of loss somewhere
is likely to lead to a "race to the
bottom" and very poor quality for all., This is not a workable business model.

In a campus setting, though (i.e., on a small sub-domain with more or less
uniform connectivity and equipment everywhere) you might usefully
take the viewpoint that a given level of congestion reports might mean
an overload of the entire local network, and thus reduce the broadcast bitrate.
This is especially true as a RTP video stream might be a substantial part of
the backbone of a campus network, while it is a very small part of the capacity
of
the current Internet backbones.

> that he (she) is getting crappy quality because

YES - unless it's so bad that there is no reception at all. This has got
to be (with FEC) kept to a level comparable to broadcast TV - a few
minutes per day at most.

> '

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 !

TCP is very aggressive from a streaming perspective.
In slow start, it keeps doubling the bit rate
until it uses up all of the available bandwidth, and then some. So, if
your streaming has to co-exist with other local TCP sessions, there will be
(short)
periods when packets will be lost because of even small TCP file transfers. It's

only on time scale longer than several RTTs that TCP can be viewed, on average,
as being a friendly and fair service.

I would argue that most congestion now-a-days is either at the source or
at the receiver. Multicasting will take care of the source problem,
so we are worried about the receiver. I still think that, if a recipient
requests
a RTP stream, it should just try and use the bandwidth requested (that is
what I meant by "aggressive," and I think Leonid too), and TCP should (as it
will)
use the remaining bandwidth. If that doesn't work on a local network, then
the user will get bad reception and the session should shut down or request less

bandwidth (see below).

This MIGHT cause problems on campus networks, but I have never heard
any reports of this. It is highly unlikely to cause problems on the backbones.

In the spirit of the Internet ("if it ain't broke, don't fix it"), I would say
that
adopting a TCP like congestion control as a standard for RTP is at best
premature. I still think that the profile should just say that RTP receivers
SHOULD
monitor for dropped packets & jitter and SHOULD implement congestion control
(shedding layers or terminating the session) if the packet loss reaches
unacceptable
levels over an extended period of time,
and that anything more involved be left out of the standard until there is
both a demonstrated need and a workable solution shown. To me, shutting things
down if you are not getting a signal through seems like common sense, and
it would take case of cases such as someone requesting a much bigger stream than
the local
network can handle.

> Regards,

                                   Regards
                                   Marshall Eubanks

   T.M. Eubanks
   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 410
   Fairfax, Virginia 22030
   Phone : 703-293-9624
   Fax     : 703-293-9609

   e-mail : [email-masked]     [email-masked]

 http://www.on-the-i.com         http://www.buzzwaves.com