Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 May 2003 10:46:28 +0200

Hi Stephen,

I have made a mistake in this. I applied the 1/4 rule also the other way 
to be used also for the receivers. This is of course in error. To verify 
that my understanding is correct I will calculate an example of my 
objection case.

Assumption. One active data sender, one receiver. Both RS and RR set. 
Which will on the sender side use the 1/4 active sender rule:
- Sender bandwidth RR+RS. The number that share this bandwidth is 2.
- Receiver bandwidth will be RR. The number in the calculation to share 
this is 1.

The interesting result in this case is that the total amount of 
bandwidth used according to RTCP algorithm is: (RR+RS)/2 + RR = 1.5*RR + 
0.5 RS. Depending on the values this can certainly be more than the sum 
of RR and RS.

It is also obvious that it works correctly for when one turns of RTCP 
Receiver reports. RR=0 results in that no sends RTCP back to the sender. 
The number of participants will be 1 at the sender side. When that SSRC 
sends data and is considered an active sender it will use the full RS 
pot for itself.

Sorry for the confusion.

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 May 2003 09:26:09 +0200

Hi Stephen,

I have know further considered the interaction between the text written 
in draft-ietf-avt-rtp-new-12 and draft-ietf-avt-rtcp-bw-5.txt. I think 
there is two problems, one with each draft.
 
- draft-ietf-avt-rtp-new-12: The algorithm in section 6.3.1 does not 
match text declaring intention further up in the draft. This should be 
resolved in some way. But it might be best to consider the RR and RS 
modifiers.

- draft-ietf-avt-rtcp-bw-5.txt: This does not present any solution on 
how to actually use the RR and RS in the RTCP report interval 
calculations. I think it should to achieve consistent behavior. Also as 
the presented RTP algorithm will not allow for turning of the receivers 
report in cases where the number of senders are more than 1/4 of the 
participants.

In the RTP draft there is chapter 6.3.1 that defines the RTCP 
transmission algorithm. The most relevant section is this:

       "1.   If there are any senders (senders > 0) in the session, but
             the number of senders is less than 25% of the membership
             (members), the interval depends on whether the participant
             is a sender or not (based on the value of we_sent).  If the
             participant is a sender (we_sent true), the constant C is
             set to the average RTCP packet size (avg_rtcp_size) divided
             by 25% of the RTCP bandwidth (rtcp_bw), and the constant n
             is set to the number of senders.  If we_sent is not true,
             the constant C is set to the average RTCP packet size
             divided by 75% of the RTCP bandwidth.  The constant n is
             set to the number of receivers (members - senders).  If the
             number of senders is greater than 25%, senders and
             receivers are treated together.  The constant C is set to
             the average RTCP packet size divided by the total RTCP
             bandwidth and n is set to the total number of members."

If one uses the bandwidth modifiers for RTCP RR and RS they are easy to 
plug in in the form of: Total RTCP bandwidth (RR+RS) and the fraction 
for senders only RS/(RR+RS) and receivers RR/(RR+RS). This works fine 
until we have situation where the senders are either 0 more than 1/4 of 
the total nr of participants. In that case according to the above 
algorithm the senders and receivers are treated together. If RR = 0, 
then the  receivers are suddenly able to send again.

My problem is that receivers behavior can't be controlled in any of the 
situations where senders are more than 1/4. I can agree that giving the 
active senders there part of the total bandwidth pool in these cases is 
the right thing to do. However giving the receivers the senders part is 
not good. Another side of this problem is that this 1/4 active sender 
rules does apply in almost all cases where one has 1-to-1 communication 
using RTP. It applies for streaming, it applies for conversational cases.

Further I can actually think that the above quoted algorithm is actually 
in error to what is intended:
 From draft-ietf-avt-rtp-new-12 section 6.2:

  "When the
   proportion of senders is greater than 1/4 of the participants, the
   senders get their proportion of the sum of these parameters.  Using
   two parameters allows RTCP reception reports to be turned off
   entirely for a particular session by setting the RTCP bandwidth for
   non-data-senders to zero while keeping the RTCP bandwidth for data
   senders non-zero so that sender reports can still be sent for inter-
   media synchronization."

This section seems to indicate that only senders should be given an 
advantage in these cases, and that turning of recievers is necessary to 
support. Based on this I would propose that algorithm is changed, my 
proposal is below. I have also changed the text to better clarify where 
you add the bandwidth values for active senders (RS) and non data 
senders (RR). It assumes that these values has been fully defined by 
either being explicit specified or using the default rules in the SDP 
RTCP bw parameter draft.

If there are any senders (senders > 0) in the session, but the number of 
senders is less than 25% of the membership             (members), the 
interval depends on whether the participant is a sender or not (based on 
the value of we_sent).  If the participant is a sender (we_sent true), 
the constant C is set to the average RTCP packet size (avg_rtcp_size) 
divided the RTCP bandwidth for active data senders (25% of rtcp_bw or 
RS), and the constant n is set to the number of senders.  If we_sent is 
not true, the constant C is set to the average RTCP packet size divided 
by the RTCP bandwidth for non data senders (75% of rtcp_bw or RR). The 
constant n is set to the number of receivers (members - senders). If the 
number of senders is greater than 25%, the interval depends on whether 
the participant is a sender or not (based on the value of we_sent). If 
the participant is a sender (we_sent true), the constant C is set to the 
average RTCP packet size (avg_rtcp_size) divided by the total RTCP 
bandwidth (rtcp_bw or RR+RS), and the constant n is set to the number of 
members. If we_sent is not true, the constant C is set to the average 
RTCP packet size divided by RTCP bandwidth assigned to receivers (b=RR 
or 75% of rtcp_bw).  The constant n is set to the number of members. If 
there is no senders, the constant C is set to the average RTCP packet 
size (avg_rtcp_size) divided by the RTCP bandwidth assigned to non data 
senders (b=RR or 75% of rtcp_bw).

To my understanding the above algorithm would handle the usage of RR and 
RS even when RR=0 in a consistent way. Of course the implementation must 
handle the division by 0 and that this will give a infinite sending 
interval.

I hope that we can quickly resolve these issues before the documents get 
published.

Best Regards

Magnus Westerlund

---

From: Stephen Casner <[email-masked]>
Date: Mon, 19 May 2003 23:08:27 -0700 (PDT)

Magnus,

> resolved in some way. But it might be best to consider the RR and RS

You are right, the text allowing the sender and receiver RTCP bandwidths
to be modified as separate parameters was added in Section 6.2 without
being addressed in 6.3.1.  My only explanation is that these sections
have two different authors.

> report in cases where the number of senders are more than 1/4 of the

I don't think this draft should say how to do the interval calculations
since that is the province of the RTP spec itself.  However, this draft
should not cause confusion.  It is reasonable to clarify the application
of the 1/4 rule.

There is a slightly bigger issue here.  The 1/4 rule originated in RFC
1889 when the interval calculation was simpler and there was no option
for changing the sender and receiver RTCP bandwidth allocations.  The
notion was that 25% of the RTCP bandwidth should be allocated to the
senders so long as the number of senders was not more than 25% of the
total participants.  The fraction 1/4 was chosen after some amount of
thought and analysis (1/8 was also considered) to give the right
emphasis to senders without causing other participants to time out.
Furthermore, those two 25%'s are supposed to be the same, such that
there is no discontinuity as the number of senders crosses 25%.  That
is, if the number of senders is exactly 25% of the number of
participants, the interval calculation produces the same result with and
without the 1/4 rule.

We have not adequately specified what the algorithm should be when RS
and RR are changed from the default values.  I had two use cases in
mind:

  - setting RR to zero to turn off feedback (with all the caveats we
    have listed);

  - changing the ratio of RTCP bw to RTP bw, either lower because the
    RTP bw is a max value and the typical value will be much lower so a
    lower RTCP bw is appropriate, or higher because the RTP bw is very
    low and the control traffic is important enough to allocate more bw
    to it.  In both of these cases, I had in mind that the RS:RR ratio
    would remain 1:3.

Under those conditions, the 1/4 rule is still fine, perhaps with some
clarification.  However, if some application sets the RS:RR ratio to be
1:9, then what happens?  If the senders share RS bw until their number
increases to 25% of the participants, that means the senders get _less_
than their fair share of the overall RTCP bw when they number between
10% and 25% of the participants.  That's not what we intended.

The relevant text from draft-ietf-avt-rtp-new-12.txt is:

   The profile MAY further specify that the control traffic bandwidth
   may be divided into two separate session parameters for those
   participants which are active data senders and those which are not.
   Following the recommendation that 1/4 of the RTCP bandwidth be
   dedicated to data senders, the RECOMMENDED default values for these
   two parameters would be 1.25% and 3.75%, respectively.  When the
   proportion of senders is greater than 1/4 of the participants, the
   senders get their proportion of the sum of these parameters.

The second "1/4" is only valid when the sender bandwidth is 1/4 of the
total.  I suggest that this text be modified as follows:

   The profile MAY further specify that the control traffic bandwidth
   may be divided into two separate session parameters for those
   participants which are active data senders and those which are not;
   let us call the parameters S and R.  Following the recommendation
   that 1/4 of the RTCP bandwidth be dedicated to data senders, the
   RECOMMENDED default values for S and R would be 1.25% and 3.75% of
   the session bandwidth, respectively.  When the proportion of senders
   is greater than S/(S+R) of the participants, the senders get their
   proportion of the sum of these parameters.

Do you (and other AVT readers) find this change acceptable?  The RFC
Editor might consider this a technical change that requires IESG
approval.

If you look at the rtcp_interval() function in A.7, the sender bandwidth
fraction and the cutover fraction of senders as members are the same
value, though it is implemented as a constant.  If the sender fraction
was set to 100%, then the non-senders would get no bandwidth.  There are
two problems: first, if there are no senders, then the non-senders get
bandwidth.  Perhaps the senders > 0 clause should be removed.  Second,
there is no protection for divide-by-zero in the case where non-senders
get no bandwidth.

As you say, the algorithm in 6.3.1 does not match the intended meaning
when the RTCP bandwidth fractions are specified separately.  I'm not
entirely satisfied with the text you've provided, though.  It is a lot
more complicated than the code in A.7.  The terms RS and RR are not
defined; we need to be careful not to tie the RTP spec to SDP.

I have to admit some concern here because we are also trying to get RFC
numbers on an accelerated basis at the request of the ITU.

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 May 2003 19:55:27 +0200

Hi Stephen,

I like the idea that Senders get there share of the total bandwidth. I 
think that work fine with the examples that I have. However I think I 
must actually ask the question: What happens the day one likes to turn 
of the senders and only have the receivers, i.e. RS=0 RR=5000?

I don't need the functionality to turn of the senders. However I think 
the bw modifier draft should explicitly talk about this case and say 
that it is not supported by the underlying RTCP mechanism.

So your proposal is to change a section of draft-ietf-rtp-new-12 to the 

>    proportion of the sum of these parameters.

I think this change is for the better and at least clarify that part. 
However what do you intend with the other relevant sections of the RTP 
draft?

I think there are two changes in the RTP draft that also needs to be made:

1. Update Section 6.3.1. Bullet 1.
2. Update the algorithm in A.7

> numbers on an accelerated basis at the request of the ITU.

If we propose these changes so that the protocol is at least as 
restricted in BW behavior I can't see major problems with the IESG. Sure 
it is not good that it has taken this long to find this problem. I guess 
this is the result of that no one has tried to apply the RTCP SDP bw 
modifier draft before. Which shows that implementation helps finding a 
lot of bugs.

However to continue the work, I have below provided a proposal for the 
A.7 code. I think that we should simply remove the senders=0 part. Then 
in cases the S/(R+S) rules kicks in the receivers will only get RR 
divided by the total nr. of participants. This will result in a 
underutilization of the total RTCP bandwidth. Let number of receivers be 
Nr, number of senders Ns and the total number of participants be N, i.e. 
N = Ns + Nr. The active senders bandwidth is S and the receivers is R. 
Then the non-utilized bandwidth, as a fraction of the total bandwidth, 
in case the fraction of senders are over the threshold, will be 
Nr*S/(N*(S+R)). Which in bandwidth is the fraction of receivers in the 
session multiplied by the bandwidth assigned to active senders.

To get some perspective on this, lets calculate a few examples. For the 
default bandwidth partition S = 0.25 and R = 0.75 the worst case will be 
  when Ns is exactly on the threshold of 1/4. This will result in 0.75 * 
0.25 = 0.1875 of the total bandwidth will not be utilized. For a case 
where Ns/N = 0.5 the underutilization is 0.5 * 0.25 = 0.125.

Some possible alternatives is considered below.

Another assignment rule I can think on would be to give the senders 
their fraction of the total bandwidth while the receivers still get a 
full share of the receiver bandwidth. This will instead result in a 
overutilization. The over utilization fraction will be R/(S+R) - Nr/N.
Utilizing the same number is the previous examples for Ns/N = 0.25 there 
will be a over utilization of 0.75 - 0.75 = 0 while for Ns/N = 0.5 it 
will be 0.75 - 0.5 = 0.25. Where the worst case is a single receiver and 
a infinite number of senders, in which the utilized bandwidth becomes 1 
+ R/(S+R). This does not seem a viable way.

A third way I can think of would be to assign the senders there portion 
of the sender bw + an equal share of the receiver bandwidth. However 
this would complicate the calculation in this case. It would of course 
utilize the whole bandwidth and also give the senders a edge in terms of 
bandwidth.

-----------
A.7 Computing the RTCP Transmission Interval

...

    double rtcp_interval(int members,
                         int senders,
                         double rtcp_bw_senders,
                         double rtcp_bw_receivers,
                         int we_sent,
                         double avg_rtcp_size,
                         int initial)
    {
        /*
         * Minimum average time between RTCP packets from this site (in
         * seconds).  This time prevents the reports from `clumping' when
         * sessions are small and the law of large numbers isn't helping
         * to smooth out the traffic.  It also keeps the report interval
         * from becoming ridiculously small during transient outages like
         * a network partition.
         */
        double const RTCP_MIN_TIME = 5.;
        /*
         * To prevent senders from getting less than a equal share of
         * the total RTCP bandwidth, a threshold is calculated. When the
         * number of senders out of the total number of participants is
         * larger than the treshold fraction they are getting less
         * bandwidth. This threshold is based on the assigned bandwidth
         * to active senders (S) and non-data senders (R). The threshold
         * is calculated as S/(S+R). For the default settings of giving
         * 1/4 of the bandwidth to active senders, i.e. 1.75% to senders
         * and 3.75% to receivers, the threshold will be 1/4 senders.
         */

        double RTCP_FRAC_SENDER_THRESHOLD = rtcp_bw_senders / 
(rtcp_bw_senders + rtcp_bw_receivers)

        /*
        /* To compensate for "timer reconsideration" converging to a
         * value below the intended average.
         */
        double const COMPENSATION = 2.71828 - 1.5;

        double t;                   /* interval */
        double rtcp_min_time = RTCP_MIN_TIME;
        int n;                      /* no. of members for computation */

        /*
         * Very first call at application start-up uses half the min
         * delay for quicker notification while still allowing some time
         * before reporting for randomization and to learn about other
         * sources so the report interval will converge to the correct
         * interval more quickly.
         */
        if (initial) {
            rtcp_min_time /= 2;
        }

        /*
         * If there were active senders, give them at least a minimum
         * share of the RTCP bandwidth.
         */
        double rtcp_bw;

        n = members;
        if (senders / members > RTCP_FRAC_SENDER_THRESHOLD) {
        	   if (we_sent) {
                rtcp_bw = rtcp_bw_senders + rtcp_bw_receivers; 

            } else {
                rtcp_bw = rtcp_bw_receivers;
            }
        } else {
        	   if (we_sent) {
                rtcp_bw = rtcp_bw_senders;
                n = senders;
            } else {
                rtcp_bw = rtcp_bw_receivers;
                n -= senders;
            }
        }

        /*
         * The effective number of sites times the average packet size is
         * the total number of octets sent when each site sends a report.
         * Dividing this by the effective bandwidth gives the time
         * interval over which those packets must be sent in order to
         * meet the bandwidth target, with a minimum enforced.  In that
         * time interval we send one report so this time is also our
         * average time between reports. In case a bandwidth value is 0
         * the interval becomes infinite, which here is represented by the
         * largest positive double value possible.
         */
        if (rtcp_bw == 0.0) {
            t = MAX_POSITIVE_DOUBLE;
        } else {
            t = avg_rtcp_size * n / rtcp_bw;
        }
        if (t < rtcp_min_time) t = rtcp_min_time;

        /*
         * To avoid traffic bursts from unintended synchronization with
         * other sites, we then pick our actual next report interval as a
         * random number uniformly distributed between 0.5*t and 1.5*t.
         */
        t = t * (drand48() + 0.5);
        t = t / COMPENSATION;
        return t;
    }

--------

Best Regards

Magnus Westerlund

S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Wed, 21 May 2003 10:18:25 -0700 (PDT)

[Note to other WG participants: I'd like to hear more opinions about
what we should do here.]

Magnus,

> of the senders and only have the receivers, i.e. RS=0 RR=5000?

If the senders are also receivers, then it is OK for them to still get
RTCP bandwidth.  It might be that this combination of parameters is
supposed to indicate that Sender Report information should not be
sent.  However, I don't think this makes sense.

> that it is not supported by the underlying RTCP mechanism.

I agree that it would be reasonable to add a note about this.

...
> 2. Update the algorithm in A.7

I see two possibilities.  If this is considered a technical change
that is not allowed at this stage, we could finesse this problem by
adding a note in both places to say that the algorithm as stated is
for the normal RTCP bandwidth allocation and must be modified if
explicit RTCP bandwidth parameters are implemented.  The justification
for this would be that the RTP spec does not define the parameters
itself, it just says profiles MAY do so.

If there is not an objection to making a more-than-editorial change,
we can remove the senders > 0 condition in both places and fix the
"senders and receivers are treated together" phrase in 6.3.1.  I don't
want to go as far as what you have proposed in modifications to A.7
because this changes the function signature which means it also needs
to be changed in other places; instead, I would leave the fraction
fixed 25%, and simply remove the senders > 0 condition.  I would add
to the comment that a check must be added to avoid division by zero if
the sender fraction is changed to 100% or parameterized.

> restricted in BW behavior I can't see major problems with the IESG.

That is not the issue.  If the RFC Editor feels this change would
require discussion by the IESG, then that is already a problem for
delay.

> Sure it is not good that it has taken this long to find this
> problem.  I guess this is the result of that no one has tried to
> apply the RTCP SDP bw modifier draft before. Which shows that
> implementation helps finding a lot of bugs.

Yes, that is certainly true.

> underutilization of the total RTCP bandwidth.

Yes, but that is a straightforward consequence of the decision to
dedicate a portion of the bandwidth to senders, and I believe it is
acceptable.  Does it make sense to have an RTP session with no data
senders?  And when no data is sent, then there is not much for
receivers to say in RTCP, either.  I suppose if RTCP were being used
on its own for a scalable-timer-based entity identification protocol,
perhaps with some other RTCP packet types defined, then this could
make some sense.  But in that case, the RS=0 and RR=n parameters can
be used to control the RTCP bandwidth at the desired level.  In fact,
if there is no data, then the concept of RTP session bandwidth is not
defined, so you'd have to be explicit about the RTCP bandwidth.

                                                        -- Steve