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

[Magnus Westerlund <[e-mail]>]

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 
following:

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

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




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

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

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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