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

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:rey@panasonic.de]
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: avt-admin@ietf.org [mailto:avt-admin@ietf.org]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
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt