Subject: [AVT] rate ctrl for unicast RTP sessions

From: Reza Rejaie <[email-masked]>
Date: Wed, 14 Nov 2001 20:19:05 -0500 (EST)

I was wondering if there has been any proposal for adding any rate ctrl
mechanism to unicast RTP sessions? Is this issue of any interest in
this working group?

ReZa

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Chuck Harrison <[email-masked]>
Date: Wed, 14 Nov 2001 17:49:24 -0800

ReZa,

Are you talking about "flow control", in the sense that the unicast
receiver tells the sender that its receive buffer is getting too
full or too empty?

If so, I started some work in this direction but it was not
completed.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  +1 360 863 8340 (voice)  PST = GMT-0800

---

From: Dorgham Sisalem <[email-masked]>
Date: Thu, 15 Nov 2001 10:44:26 +0100

Hello,

we have done some work on TCP-friendly rate control based on RTP (for
unicast as well as multicast), see

D. Sisalem and A. Wolisz, "LDA+ TCP-Friendly Adaptation: A Measurement
and Comparison Study," in the 10th International Workshop on Network
and Operating Systems Support for Digital Audio and Video
(NOSSDAV'2000), June 25-28, 2000, Chapel Hill, NC, USA   

D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly congestion control
framework for heterogenous multicast environments," Eighth
International Workshop on Quality of Service (IWQoS 2000), 5-7 June
2000, Pittsburgh.   
http://www.fokus.gmd.de/research/cc/glone/employees/dorgham.sisalem/private/papers.html

Cheers

-- 
Best regards,
 Dorgham                            mailto:[email-masked]

---

From: Reza Rejaie <[email-masked]>
Date: Thu, 15 Nov 2001 15:37:45 -0500 (EST)

Chuck,

No, I am talking about congestion control, i.e. ajusting transmission rate
of a session as network behavior (e.g. loss rate, rtt, ..) changes. So it
happens in a shorter time scale (e.g. per rtt) than flow control.

ReZa

---

From: Reza Rejaie <[email-masked]>
Date: Thu, 15 Nov 2001 17:35:20 -0500 (EST)

Dorgham,

I know about your work and other existing TCP-friendly rate control
mechanisms such as TFRC, Binomial CC, TEAR, RAP, etc. I was asking
about any work on how one of these rate control mechanisms can/should
be integrated into a multimedia application. More specifically, the
interactions among rate ctrl module, application, and RTP. For example,
one approach is to have rate ctrl module notify the application to
send a packet. This idea suggests that the rc module should maintain
the control of execution while mm applications often would prefer
to control the execution. The work on congestion manager suggests
one solution but it assumes that the rate ctrl functionality is
implemented in the kernel.

Admittedly, these issues are rather similar to API issues, but
they could significantly affect inegration of rc and rtp with mm apps.
We have done some work on this topic and if there is any interest, I
can provide more details.

ReZa

---

From: Dorgham Sisalem <[email-masked]>
Date: Fri, 16 Nov 2001 10:34:12 +0100

Hello,

My belief is that rate control needs to take the characteristics of
the mm content and communication scenario in consideration (rate
control should not just be based on losses and delays) therefore such
a rate ctrl module needs to be closely integrated with the
applications (even though this is from an engineering point of view
not optimal as each application will need to incorporate such a
module)

cheers

---

From: Reza Rejaie <[email-masked]>
Date: Mon, 19 Nov 2001 12:19:23 -0500 (EST)

> control should not just be based on losses and delays) therefore such

The bottom line is that over some "time-scale" the avg sending rate of
your application should match with its changing fair share of bandwidth
in the Internet. To determine your fair share of bw, you need to rely on
network feedback (loss, rtt, change in throughput, marked pkts, whatever)
and use a slow or fast rate ctrl algorithm (whichever is more suitable for
your application) to adjust the tx rate. Except for selecting one of
the known rate ctrl algorithms, one can not further customize a rate ctrl
mechanism to meet "the characteristics of the mm content".

Most of the mm content require rather constant avg tx rate whereas
rate ctrl results in potentially wide changes in bw. The main challenge
is how to perform rate control while minimizing the negative impact on
quality of delivered stream.

> not optimal as each application will need to incorporate such a
right, so every application-developer may not implement a rate ctrl
mechanism correctly. No matter where the rate ctrl mechanism is
implemented, its integration into mm appliction is still an issue
because the rc module determines the rate based on network feedback
and application should limit its tx rate even if it is *not* appropriate
for its content.

My initial point was that regardless of the details of the rate ctrl
mechanism, one might be able to present a rather generic way to integrate
rate ctrl module with mm applications which might be of interest to this
working group.

ReZa