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

From: "Peter Barany" <[email-masked]>
Date: Wed, 23 Jul 2003 10:45:20 -0500

Hi,

Just for clarification, in Appendix A.7 of RFC 1889 bis Internet draft have
the following changes been agreed to (or are these changes not required per
the agreed changes to the RTCP bandwidth modifier Internet draft)?

(1) "RTCP_RCVR_BW_FRACTION = 0.25"
changed to
"RTCP_RCVR_BW_FRACTION = rtcp_bw_senders/(rtcp_bw_senders +
rtcp_bw_receivers)"

and

(2) "senders > 0" removed?

Thanks.

Regards,

Pete

-----Original Message-----
From: Jose Rey [mailto:[email-masked]]
Sent: Monday, June 16, 2003 6:32 AM
To: Stephen Casner; Magnus Westerlund
Cc: IETF AVT WG
Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Stephen
> Casner
> Sent: Monday, June 16, 2003 8:47 AM
> To: Magnus Westerlund; Jose Rey
> Cc: IETF AVT WG
> Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt
>
>
> Some more thoughts on this:
>
> To simplify the unicast streaming application, we could specify that
> when RTCP bw is specified with RS and RR those values are used
> separately for senders and non-senders without any consideration of
> treating senders and receivers together when the number of senders is
> greater than RS/(RS+RR).

I think this is the best and easiest solution. In 3GPP unicast streaming it
is
the server that sets the RS and RR values, that means the server should
consider
well how much bandwidth it is needed for own reporting and for the sender's.
There's no case where the algorithm must adapt, the scenario is rather
static.

>
> However, that would not be good for conversational applications
> (unicast or multicast) because the classification as sender changes
> over time.  At times when both ends have sent within two intervals,
> they would be using the RS bw only and ignoring the RR bw.  To get
> around this we could set RS to be the total, and RR zero, but then if
> one was sending and the other just listening for a long time, the
> listener would get nothing.  For these applications, you need the
> smooth transision that the existing algorithm was intended to
> provide.
>
I see. I was referring more to the streaming unicast scenario. I guess my
characterization was not accure enough.

cheers,

Jose

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

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

---

From: Stephen Casner <[email-masked]>
Date: Wed, 23 Jul 2003 11:41:35 -0700 (PDT)

Peter,

> (2) "senders > 0" removed?

Those changes have logically been agreed, but the edits are not
exactly as you state.  In Section 6.2, the proportion of senders has
been changed from 1/4 to S/(S+R).  In Section 6.3.1 item 1, the
"senders > 0" clause has been removed, and the following text added at
the end:

      As stated in Section 6.2, an RTP profile MAY specify that the
      RTCP bandwidth may be explicitly defined by two separate
      parameters (call them S and R) for those participants which are
      senders and those which are not.  In that case, the 25% fraction
      becomes S/(S+R) and the 75% fraction becomes R/(S+R).  Note that
      if R is zero, the percentage of senders is never greater than
      S/(S+R), and the implementation must avoid division by zero.

In Appendix A.7, the "senders < 0" clause has been removed and the
inequality is changed from "<" to "<=" so that the inequality is
always true when RTCP_SENDER_BW_FRACTION is 1.0:

       if (senders <= members * RTCP_SENDER_BW_FRACTION) {

However, your change (1) above has not been made because I did not
want to make modifications to the extent that would be required to add
rtcp_bw_senders and rtcp_bw_receivers as arguments to the function and
all calls to it.  Instead, I added the following paragraph just before
the rtcp_interval() function:

   These functions would have to be extended for an implementation
   that allows the RTCP bandwidth fractions for senders and
   non-senders to be specified as explict parameters rather than fixed
   values of 25% and 75%.  The extended implementation of
   rtcp_interval() would need to avoid division by zero if one of the
   parameters was zero.

The full RFCs should be released within a few days.

                                                        -- Steve