Subject: RE: New congestion control text in RTP spec

From: Dorgham Sisalem <[email-masked]>
Date: Fri, 11 Aug 2000 18:48:10 +0200

>> The profile draft states :
>>
>>              If best-effort service is being used, RTP receivers SHOULD
>>              monitor packet loss to ensure that the packet loss rate is
>>              within acceptable parameters. Packet loss is considered
>>              acceptable if a TCP flow across the same network path and
>>              experiencing the same network conditions would achieve an
>>              average throughput that is not less the RTP flow is
>>              achieving.
>>
>> [...] several MP3 packets  will be lost in a row. I would fear that any
>> simple minded
>> congestion monitoring would then conclude that there was congestion, and
>> ramp down the UDP.

>Then don't use a simple minded congestion monitoring scheme!
>Schemes like TFRC have been designed to compete fairly with TCP.
>(However, in your example, where you send 90 kbit/s RTP over a 128 kbit/s
>link, TFRC would still try to regulate that down to around 64 kbit/s if you
>have a bulk data TCP connection going at the same time.)

well not really, TCP-friendly adaptation schemes assume not only 
that the TCP and UDP flows suffer from similar losses and delays 
but also have the same packet size. Thereby, an equation based 
scheme would not result in equal distribution in this case 

>> "If best-effort service is being used, RTP receivers SHOULD
>> monitor packet loss to ensure that the packet loss rate is
>> within acceptable parameters. Packet loss is considered
>> acceptable for a receiver if the RTP flow to that receiver achieves an
>> average throughput that is not less than 90% of the nominal
>> bandwidth for that  RTP flow."

>Now that would be a "simple minded congestion monitoring" scheme, indeed!
agreed, I would reformulate the sentence to:

"If best-effort service is being used, RTP receivers SHOULD
monitor packet loss, delay and jitter values and use some congestion
control scheme that on the one hand aims at achieving a fair bandwidth
distribution among competing flows and an acceptable perceived QoS.
As an example for a definition of a fair bandwidth distribution would
be to require that a TCP flow across the same network path and
experiencing the same network conditions would achieve an
average throughput that is not less the RTP flow is achieving.
The definition of an acceptable perceived QoS might be defined in terms
of loss and delay ranges as measured at the application level and
indicated in the RTP profile."

Regards
	Dorgham

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Fri, 11 Aug 2000 13:55:31 -0400

> indicated in the RTP profile."

Hello;

   There are two kinds of congestion control, which could be loosely called  on the backbone, and
at the receiver. TCP needs to worry about both, as it will seize ALL of the bandwidth it can.
I would strongly argue that multicast RTP/UDP mostly needs to worry about the receiver congestion
problem. I would strongly argue that if I'm watching a video (say) and start an FTP session or
click on a web site button, that I do NOT in general want my TV picture to degrade or disappear.
I have chosen a given level of reception; please do not I assume that I want less unless I ask for
it, or unless it's impossible. I think that most viewers or listeners to Internet multicast services would feel the
same way.

   Also consider the zeroconf home network case, which I think in the long run will dominate the use of these
services. <insert name of favorite older relative> is at home listening to an Internet radio using multicast
RTP over a home LAN. The TV remote control (say) starts its daily  automatic download
of the latest channel guide using TCP. The radio reception gets progressively worse over a 5 minute
period. My mother concludes the radio is defective, and throws it
out. Is that really what we want ?

I would thus argue that

 1.) - An equal sharing between TCP and multicast RTP/UDP is NOT what should be done, even
if the RTP session could figure out what TCP sessions were up to, and

 2.)  - multicast RTP should preserver even given occasional episodes of congestion, as these are
likely due to TCP slow start/congestion control and

3.) As Dorgham says, multicast RTP should worry most about reception at the receiver, and only give
up or degrade service if conditions are truly unacceptable.

What, you may ask, if I ask for 1.5 mbit / sec video over a 56k phone line ? Well, I won't get
reception, and will then turn it off or seek some other service.  I do not think that this is the type
of congestion we are fighting here!

--
                                 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.buzzwaves.com            http://www.on-the-i.com

---

From: Dorgham Sisalem <[email-masked]>
Date: Sat, 12 Aug 2000 17:17:11 +0200 (MET DST)

> it, or unless it's impossible. I think that most viewers or listeners to Internet multicast services would feel the
this is a little bit too user centric. The main goal of congestion control
is to avoid congestion in the network. What I wanted to stress here is
that congestion control schemes for multimedia communication should
combine the user perceived QoS aspects with network congestion avoidance
(i.e.,
the congestion control schemes should not only base their control behavior
on network parameters such as loss and delay but also take application and
user constraints into account as well. While this might cause a congestion
control scheme to be temprarily unfair towards other streams but on the
whole one it could be made to act fair over longer time periods.

Dorgham

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Sun, 13 Aug 2000 08:06:55 -0400

Hello;

> is to avoid congestion in the network. What I wanted to stress here is

It used to be, Internet eons ago. Is it now ? Is it likely to be in the near future ? And what do you mean by "the network" ?
A local LAN, or a backbone ? And is a TCP system really the best on the local LAN ?
Consider the case of the recent Napster flaps, when some colleges found that 80% of
their in-bound traffic was taken over by many Napster TCP sessions, and had to specifically
shut it down :

1.) Many TCP sessions are not benign on a local LAN.
2.) I heard of NO (as in ZERO) reports of all of this traffic being a problem on any
backbone.
3.) The congestion control implemented was manual intervention.

As I said before, if the local net is just whatever the user doing this side of a DSLAM, RTP should
be aggressive versus local TCP, as it is doing what the user has requested.

Consider a college type situation. A few RTP multicast streams of audio or low quality video will not seriously
congest even a 100 mbps Ethernet. If every student decides to listen to a different station, then
this might be a problem, but NO pre-planned congestion control is likely to fix it, and it will
fix itself, as the reception quality will be bad and people will turn it off.
In the worse case, the network operators
will have to intervene manually basically no matter what RTP is doing, no different from TCP.

I have had backbone people tell me that, with all of the dark fiber out there,  even dozens of "little" 200 kbps or
1 mbps multicast streams will be "in the noise" in terms of usage on their backbones.
I would take them at their word :)

And finally, RTP should be "user-centric" This is not a dirty word. If there are no users, there
will not be any RTP. It is different from TCP in that regard - no matter what sort
of layering you are doing, the dynamic range in bandwidth over which RTP can still provide an
acceptable user experience is pretty small. By contrast, the TCP dynamic range is
enormous.

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Sun, 13 Aug 2000 08:02:02 -0400

Hello;

As I said before, if the local net is just whatever the user doing this side of a DSLAM, RTP should
be aggressive, as it is doing what the user has requested.

Consider a college type situation. A few RTP multicast streams of audio or low quality video will not seriously
congest even a 100 mbps Ethernet. If every student decides to listen to a different station, then
this might be a problem, but NO pre-planned congestion control is likely to fix it, and the network operators
will have to intervene manually basically no matter what RTP is doing.

I have had backbone people tell me that, with all of the dark fiber out there,  even dozens of "little" 200 kbps or
1 mbps muticast streams will be "in the noise" in terms of usage on their backbones.
I would take them at their word :)

And finally, RTP should be "user-centric" This is not a dirty word. If there are no users, there
will not be any RTP. It is different from TCP in that regard - no matter what sort
of layering you are doing, the dynamic range in bandwidth over which RTP can still provide an
acceptable user experience is pretty small.

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks

---

From: Dorgham Sisalem <[email-masked]>
Date: Sun, 13 Aug 2000 16:35:38 +0200 (MET DST)

> It used to be, Internet eons ago. Is it now ? Is it likely to be in the near future ? And what do you mean by "the network" ?

a network is any part between the sender and receiver that might get
congested

> A local LAN, or a backbone ? And is a TCP system really the best on the local LAN ?

TCP might not be the PERFECT system, but I guess this is irrelevant and
there is really no reason in starting a flame war again about if TCP is
good or
bad, it is here and it will stay so I do not see the reason behind this
question
 
> their in-bound traffic was taken over by many Napster TCP sessions, and had to specifically
so what? 

> 2.) I heard of NO (as in ZERO) reports of all of this traffic being a problem on any
UDP based multimedia traffic might not be more than noise comaped to the
TCP part but this is supposed to change

> 3.) The congestion control implemented was manual intervention.
??? how are we supposed to understand this now? Disabling some kind of
traffic might solve the most serious problems but is not a solution in
itself (web traffic seems to be taking a large share of the bandwidth on
most networks, shoud we just shut it out to save ftp and mail flows??)
 
> be aggressive, as it is doing what the user has requested.
This might be OK if the sum of flows that do that is small relative to the
overall number,as soon as this changes you will get into trouble -or maybe
we can start having different protocol stacks for the LAN and WAN cases
and the user would need to specify what mode to use (:-)
 
> will have to intervene manually basically no matter what RTP is doing.
TCP has done a good job in fixing congestion for ages now so what is the
argument against doing similar things with UDP. This napster example is
not
a very convincing one. so there were too many TCP flows which the
administrators decided to be not very usefull and and that slow down more
important
ones (such as web traffic???), however even under this situation, all
users get some bandwidth.

> acceptable user experience is pretty small.
lots of video compression styles provide for a wide range of adaptation,
and there is lots what one can do with audio as well.

This discussion is getting too relegious (adapt or not adapt) and I am not
sure the rem-conf list is the right place for that, so unless lots of
other
people would like to join the discussion we should do it directly?

Regards

---

From: Leonid Rosenboim <[email-masked]>
Date: Mon, 14 Aug 2000 08:43:22 +0200

Thomas Marshall Eubanks wrote:

> [snip]
>
> As a guess, I would say
>
> - Multicast RTP's potential for DOS type attacks is small (it's one to many, not many to one).
>

If this "one to many" mechanism is coupled with a "reflector" mechanism, where all
reflected traffic is directed at a "target" site, then DDOS is possible. Other one-to-many
mechanisms (e.g. directed broadcast) have caused havoc in the past.

>
> - at present, there is strong potential to hack INTO rtp streams - inserting bogus
> content, or denying users the RTP. I.e., RTP itself is sensitive to DOS at present.
> Maybe SSM and other uses of IGMP v3 can prevent this to some degree.
>

I would suggest not to take this lightly - suppose a hacker can insert his own "words of truth"
into a very popular radio channel on the Internet, and easily get the attention of millions
of people ? Spam e-mail seems quite benign when compared to an effect of this.

>
> - multicasting one to many plus a virus/worm/trojan horse etc. inserted into the stream could be devastating.
> Spread times could be measured in milliseconds, not hours or days.
> This is a real problem if browsers are going to be playing streams or displaying
> "pushed" text. Neither SSM nor RTP can prevent this, as it is really a client-side problem.
>

Indeed it seems that Multicast could prove an exremely powerful exploit due to its rapid
spread time, and if it becomes deployed on a large scale, this could lead to disasters.
I do not agree that RTP can not prevent this, there is sufficient knowledge out there
which can be used to enhance these protocols for better robustness, and a set of
implementation guidelines which will result in interoperable applications which are
also resistent to at least the sorts of attacks which are already known to occur.

Leonid

---

From: "Gamze Seckin" <[email-masked]>
Date: Mon, 14 Aug 2000 13:02:33 -0700

I don't think this discussion is to talk about disadvantages of TCP..and
surely TCP will be around for some time..
Since a congestion ctrl section is to be added to the RTP draft I guees it
is a good point to clarify RTP's assertiveness...
I also think that RTP congestion control should be more aggressive and not
bound by TCP performance.
I am sure many people are interested in this discussion. but in case you
decide to continue off-line please do include my email..

Thanks,
gamze

=================
Gamze Seckin, Ph.D.
Research Engineer, Luxxon Corporation
(408) 573 8400x218
www.luxxon.com

----- Original Message -----
From: Dorgham Sisalem <[email-masked]>
To: Thomas Marshall Eubanks <[email-masked]>
Cc: Dorgham Sisalem <[email-masked]>; <[email-masked]>
Sent: Sunday, August 13, 2000 7:35 AM
Subject: Re: New congestion control text in RTP spec

> >
> > It used to be, Internet eons ago. Is it now ? Is it likely to be in the
near future ? And what do you mean by "the network" ?
> > I have had backbone people tell me that, with all of the dark fiber out
there,  even dozens of "little" 200 kbps or

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Mon, 14 Aug 2000 16:18:26 -0400

> decide to continue off-line please do include my email..

I have nothing against TCP - it developed over many years and is probably THE best
congestion control algorithm in massive use today. I just don't think that it is
too appropriate a paradigm for large scale multicasting with receiver based congestion control,
and the draft as it stands worries me.

I think that the draft should be inclusive in its approach to congestion control.
I believe that TCP was around for about 8 years before there was any congestion control, and then
it was a near crisis that mandated it. I do
not think the RTP will solve all of its congestion control problems just out of the box :)

                                 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

---

From: Dorgham Sisalem <[email-masked]>
Date: Tue, 15 Aug 2000 17:11:49 +0200

> surely TCP will be around for some time..
well that is what I wanted to avoid

> is a good point to clarify RTP's assertiveness...
sure

> bound by TCP performance.

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. 

Regards
	Dorgham

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Tue, 15 Aug 2000 18:13:19 +0200

> ALL of the bandwidth it can.

Actually, it does not have the foggiest idea which of these two it is
worrying about...

> problem.

You have to consider fairness in the highly statistically multiplexed
backbone as well as fairness in the lo-stat-mux links *that aren't entirely
yours*!
The only links where the kind of control you are hinting at might work are
the ones where all competing flows are your own flows.
I don't think we have a way to handle these differently (or even know they
are there)...

> I would strongly argue that if I'm watching a video
> (say) and start an FTP session or

How does the TCP flow emanating from the FTP server know that it should not
compete with your RTP stream?
(Actually, how does it know *that* its bottleneck is caused by competing
with it?)

I think something like ECM, but receiver-oriented, could help in the case
that you are receiving multiple flows that you want to compete in a specific
way.
(In the example, the FTP client's TCP stack could control its window updates
such that it throttles the FTP server's TCP just right.)
I just don't think we know how to do this.

Gruesse, Carsten

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Tue, 15 Aug 2000 13:24:21 -0400

That was not quite what I got from the text. I am pretty much in full agreement
with this interpretation.

                                   Regards
                                   Marshall Eubanks

   T.M. Eubanks

---

From: Mark Handley <[email-masked]>
Date: Tue, 15 Aug 2000 10:27:45 -0700

>out. Is that really what we want ?

However if your mother is listening to a radio show being streamed
over HTTP (as many people currently do) and you suddently start
listening to your RTP multicast session, your mother will still throw
the radio out.

The point is that you can't decide which traffic needs priority from
the transport protocol it's using.  If you need to make value
judgements and differentiate between traffic flows, you need to use
differentiated services (or reservations) to do it.  You don't want to
engineer those value judgements into the congestion control mechanisms
for a particular transport protocol.

Cheers,
	Mark

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Tue, 15 Aug 2000 13:41:45 -0400

> Actually, it does not have the foggiest idea which of these two it is

Nor should it...

> I don't think we have a way to handle these differently (or even know they

I  say, try a simple minded receiver based congestion control first, and see
if it works or leads to problems. I think that in practice even an aggressive
RTP
would not cause many problems; we shall see. There isn't enough of it
at present to break the Internet, that's for sure.

> compete with your RTP stream?

It won't. It doesn't have to, nor, really, should it.

I have two cats. One eats more or less a fixed amount, the other eats
everything
put in front of it and then the other cat's and then goes hunting for more. The

first cat has to be somewhat aggressive to get anything to eat at all, so it
is. Although
this is a true story, I could just as well rename these cats RTP and TCP.

> I just don't think we know how to do this.

Is ECM deployed anywhere ? Multicasting is hardly deployed at all now. Maybe
SSM will help, but to
ask it to wait for something further will probably kill it commercially.

> Gruesse, Carsten

I would remind people that we are discussing the profile draft text on
congestion control, which
I regard as flatly unacceptable and likely to be never honored by large scale
broadcasters. I suggested an "aggressive" receiver based alternative. Maybe a
compromise would be to just leave it as

             "If best-effort service is being used, RTP receivers SHOULD
             monitor packet loss to ensure that the packet loss rate is
             within acceptable parameters."
followed by
             "Congestion control MAY be  implemented through
             congestion control mechanisms to adapt the transmission
             rate (or the number of layers subscribed for a layered
             multicast session), but in any case  receivers SHOULD  to leave
             the session if the loss rate is unacceptably high."

Which fudges the definition of "acceptable", which is probably correct
at this point.

                                   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

---

From: Kavé Salamatian <[email-masked]>
Date: Tue, 15 Aug 2000 20:40:17 +0200

Hello everybody,

Sorry for introducing myself in this interesting discussion. But I have two
ingenous question:
1- What is network state ??????
2- What is application needs ?????

I know the answer to this two question is very difficult but I think that if
we can at least understand where is the difficulty we will have make a step
further.

Some remarks about the first question.
This question is in fact a fundamental question in IPPM framework. What is a
good IP Performance measure ?? The network state is, I think, an abstract
hidden variable, that cannot be seen directly by any end user. End users see
only its reflect, loss, delay, etc .... The problem is about how to
reconstitute the hidden variable (network state) from its noisy observation
(loss rate, delay variation, etc). However, to restrict the search domain
for the hidden variable we use an underlying model for the network relating
observation to the hidden variable. For example in TCP the network is a
rigid pipe containing a full TCP window. All the problems of TCP are related
to this underlying model assumption. At the other side some multimedia
applications need an underlying model of the connection that is similar to a
variable valve with varying rate. In my point of view the first question to
ask (or to answer) is what is the underlying model we want to use or at
least to list the different possible underlying models. Maybe a draft
listing different approach will be valuable.

The second point is how to transform observation to states in the underlying
model. This question was answered in the TCP framework by the well known TCP
congestion control (the estimated network state is the TCP window length).
It maybe need some work on the other framework. I do not want to enter into
technical discussion about this on this list but I will be interested to
discuss offline.

About the second question I do not think that any generic framework can be
developped. Application have too wide spectrum of needs. The meaning of
smooth QoS used by Dorgham is particuliar to each application.

Afterall I agree with the underlined interpretation of Dorgham, but, in my
point of view it does not solve any problem as it is to much general and too
much concept need to be defined. Network state ?? Application needs ??
smooth perceived behavior ?? starving competitor flows ??

Regards

Kavé Salamatian

Assistant Professor, Université Paris VI, Paris France

---

From: Dorgham Sisalem <[email-masked]>
Date: Wed, 16 Aug 2000 16:58:14 +0200

[email-masked] said:
> About the second question I do not think that any generic framework 
> can be developped. Application have too wide spectrum of needs. The 
> meaning of smooth QoS used by Dorgham is particuliar to each 
> application.

> Afterall I agree with the underlined interpretation of Dorgham, but, 
> in my point of view it does not solve any problem as it is to much 
> general and too much concept need to be defined. Network state ?? 
> Application needs ?? smooth perceived behavior ?? starving competitor 
> flows ?? 
I do agree it will very difficult to specify a general application 
framework
(even though we already made an attempt at that, see:
ftp://ftp.fokus.gmd.de/pub/step/papers/Sisa0002:Constrained.ps.gz )

Still I believe that the congestion text should not limit itself to 
this TCP-friendly definition and indicate clearly to the implementor of 
the congestion control scheme that he/she better take a good look at 
what the congestion control mechansim is doing to the quality as seen 
by the user

Dorgham

---

From: Leonid Rosenboim <[email-masked]>
Date: Mon, 21 Aug 2000 10:11:41 +0200

Dear Collegues,

Please allow me to add a brief comment wirh respect to congestion control
in RTP:

Congestion control was required to be added to TCP because TCP has a
policy of packet retransmission which does not have a limit on the load
(or attempted throughput) it inserts into the network. This total lack of
limits
was the cause of the congestion/collapse fenomena which was observed in
the early large deployments of IP networks which carried many TCP streams.

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.

In the case when retransmission error control is implemented, there should
be
an uppe rlimit on the total amount of bandwidth generated by all traffic
including
retransmissions and handshakes, to avoid the TCP-like behaviour which
required
congestion control in the first place.

Hope this comment is useful,

Leonid Rosenboim

---

From: Dorgham Sisalem <[email-masked]>
Date: Mon, 21 Aug 2000 11:59:20 +0200

[email-masked] said:
> policy of packet retransmission which does not have a limit on the 
> load (or attempted throughput) it inserts into the network. This 
> total lack of limits was the cause of the congestion/collapse 
> fenomena which was observed in the early large deployments of IP 
> networks which carried many TCP streams. 

I would say this is a little bit over simplistic, the goal of 
congestion control is to figure out the appropriate transmission rate 
to use that does not lead to network overload. If a few or all RTP 
senders start transmitting data at a very high rate (say their Ethernet 
line speed) because the user thinks that his video stream should get 
all bandwidth available then we will soon end up in a very bad 
situation and have a new form of netowrk collapse (regardless if we are 
using retranmissions or not

Dorgham

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Mon, 21 Aug 2000 07:20:51 -0400

> Please allow me to add a brief comment wirh respect to congestion control

<snip>

> congestion control in the first place.

I would argue that re-transmission congestion control is indeed a potential
problem, but for the RMT working group. I do not believe that the draft
profile is intended for this case,  although wording could be added :

"More aggressive TCP like congestion control MUST be added in case
relieable multicast retransmission error control is being used."

                                   Regards
                                   Marshall Eubanks

   T.M. Eubanks

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Mon, 21 Aug 2000 07:27:15 -0400

> I would say this is a little bit over simplistic, the goal of

I think that what Leonid says here is the literal truth.

> using retranmissions or not

And any form of receiver based RTP congestion control, no matter how
simple minded, will shut down the
reception in this case, because the packets will not get through.

I would argue, in the spirit of "if it ain't broke, don't fix it", that
this
scenario has not yet been a problem in practice, that it is unclear that
it will become a problem in practice, and furthermore it is unclear how
it should be implemented in practice, nor how to keep it, if implemented,
from trashing the RTP stream being delivered, so that it is at best way
premature to call for its inclusion in the draft profile, except maybe as
a
MAY.

                                   Regards
                                   Marshall Eubanks

   T.M. Eubanks

---

From: "Madan A S" <[email-masked]>
Date: Tue, 22 Aug 2000 13:33:24 +0530

> is constant, and does not increase when pakcet loss or network delay
> increases.
> 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 ?

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Wed, 23 Aug 2000 15:04:34 -0400

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

We are assuming multicasting - this is not true in the unicast case.

In multicasting, assuming at least one receiver, the source sends
out one and only one stream. (In case of N multiple streams to do FEC/striping,
then, assuming at least one listener for each sub-stream, it sends
out exactly N streams.)

That is the real economic reason to do multicasting.

--
                                 Regards
                                 Marshall Eubanks

T.M. Eubanks

---

From: Leonid Rosenboim <[email-masked]>
Date: Thu, 24 Aug 2000 09:06:32 +0200

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

To put it back into context - the bitrate is constant with respect to network
behaviour,
i.e. it does not change when network delay and packet loss chanmges.
In otehrwords,  there is an upper limit on the number
of packets per second generated by any RTP sender, which does not change due
to increased packet loss, contrary to TCP which DOES increase the number of
packets
per second transmitted when packets loss increased to overcome the lost packets.

As to the unicast vs. multicast scenario, I do not think it matters, it is true
that for unicast
the actual packet rate is N times larger (where N is number of listeners), but
there still
is an upper limit, which does not change when packet loss (or network delay)
increase.

Also, I do not see a material difference here between unitact and multicast,
after all multicast
can be viewed as a set of unicast sessions where data for multiple listeners is
duplicated
by Routers (which are closer to the listener) rather then Servers at the source.

Hope this helps,
Leonid