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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Jun 2003 19:03:55 +0200

Hi Steve, others.

I have been think over this problem some more. I have one problem with 
the proposed algorithm. The proposed algorithm seems to be the correct 
one when one comes to conversational, confernce or multicast 
applications where there is a potential large number of receivers and 
senders needs to be prioritized to provide synchronization data.

However I have been thinking on the case of on-demand streaming. In this 
case one has normally a single sender and one receiver. In this case it 
is no question that the sender will get the complete RS pool. However in 
this case on is actually interested in giving the receiver the complete 
RR pool. The sender will suffice with the given RS pool as this can 
easily be calculated and the SR information is less important for 
synchronization. The receiver instead has a lot of interesting to report 
and creates large packets that it want to send often. Therefore a larger 
RR bandwidth is motivated.

In the above case on would like to send receiver reports utilizing the 
full RR pot for the receiver. One might also want to assign more 
bandwidth to RR then to RS. What happens in this case, as can be seen 
below, is that the receiver actually gets less.

For RS > RR:
Receiver RTCP bandwidth = RR/1
Senders bandwidth = RS/1

For RS < RR
Receivers RTCP bandwidth = RR/2
Senders bandwidth = (RS + RR)/2

This get even worse if one would use SSRC multiplex RTP retransmission. 
In this case one gets two senders and one receivers as long as 
retransmission occurs more than every two RTCP reporting intervals.

For RS/2 > RR:
Receiver RTCP bandwidth = RR/1
Senders bandwidth = RS/2

For RS/2 < RR:
Receiver RTCP bandwidth = RR/3
Senders bandwidth = (RS+RR)/3

If would have been interesting to have an attribute that tells the RTCP 
implementation to do the sharing for senders, or strictly assign within 
  the group of senders or receivers.

I also would like to have more input about this issue from other people.

Best Regards

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: "Jose Rey" <[email-masked]>
Date: Fri, 6 Jun 2003 14:49:46 +0200

Hi all,

in my understanding the problem is the following: RTCP BW modifiers don't work
for RTP unicast with the algorithm in RTP draft annex A.7. And since unicast is
a very important application which will be using these modifiers (at least 3GPP
will be using them), it is necessary to do something about this. An added side
problem is that you cannot turn the receivers' RTCP off, because (as explained
below) all session participants are treated equal.

Now in detail, applying the algorithm in RTP-draft section A.7 for unicast, the
end result is that senders AND receivers equally share the bandwidth, each
getting a value equal to (RR+RS)/members, because the if-clause is always false.
This clearly cancels the whole purpose of the RTCP BW modifiers (again, just in
the unicast case). This gets even worse if RTP retransmission is used (where
different SSRCs might be used to multiplex media and retransmissions) as the
bandwidth that one wants to dedicate to the receiver is actually shared equally
between an increased number of SSRCs.

If changing the algorithm is too much of a change at this stage AND this shall
not be solved by draft-ietf-avt-rtcp-bw-05.txt, then the only solution I see is
to tell RTCP through SDP who uses which bandwidth values, but this needs also of
another rtcp_interval() algorithm that accepts these values as parameters (as
Magnus proposed in his code). Makes this sense to all?

Would another draft be the rigth place for this other algorithm? Would that
constitute a new profile?

Thanks,

Jose

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Magnus
> Westerlund
> Sent: Wednesday, June 04, 2003 7:04 PM
> To: Stephen Casner
> Cc: IETF AVT WG
> Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt
>
>
> Hi Steve, others.
>

---

From: Stephen Casner <[email-masked]>
Date: Sun, 15 Jun 2003 17:35:13 -0700 (PDT)

> senders needs to be prioritized to provide synchronization data.

So far I agree.

> RR bandwidth is motivated.

I don't see why the synchronization information is any less important
in this case than for the earlier ones.

> Senders bandwidth = (RS + RR)/2

While this arithmetic is correct, I'm not sure it matters.  There are
two considerations you have not included in your analysis:

1.  The reporting interval is determined by dividing the average
    packet size by the calculated bandwidth.  Since the average packet
    size is calculated using all the RTCP packets from both senders
    and receivers, then receivers will be getting a larger share of
    the bandwidth because their RTCP packets are larger.

2.  For narrow channels, the 5 second minimum will constrain the
    interval calculation more than the default 5% (or 3.75%) RTCP bw,
    so unless the application needs to severely constrain the bw to
    make the interval even longer, it won't make a difference.

> Senders bandwidth = (RS+RR)/3

If RTP retransmission is used, I would assume that AVPF is also being
used, and therefore the interval calculation is modified.  Given the
variability in both data bw and RTCP bw depending upon the error rate,
there has got to be significant headroom between the base data rate
and the channel capacity, so precisely controlling the RTCP bw should
not be an issue.

On Fri, 6 Jun 2003, Jose Rey wrote:

> in my understanding the problem is the following: RTCP BW modifiers
> don't work for RTP unicast with the algorithm in RTP draft annex
> A.7. And since unicast is a very important application which will be
> using these modifiers (at least 3GPP will be using them), it is
> necessary to do something about this.

Unicast is not the right characterization.  For conversational
unicast, which has symmetric requirements, there should be no problem.
Unicast streaming, where the data transmission is unidirectional, is
where the questions arise.  Furthermore, it is the inclusion of only
two participants, not the use of unicast transmission, that might make
this case different.  Note that there can be RTP sessions with more
than two participants using unicast through an RTP mixer.

> An added side problem is that you cannot turn the receivers' RTCP
> off, because (as explained below) all session participants are
> treated equal.
> Now in detail, applying the algorithm in RTP-draft section A.7 for
> unicast, the end result is that senders AND receivers equally share
> the bandwidth, each getting a value equal to (RR+RS)/members,
> because the if-clause is always false.

Assuming a modification to use RS/(RS+RR) as the
RTCP_SENDER_BW_FRACTION rather than a fixed .25, then the algorithm in
A.7 gives non-data-senders zero RTCP bw when RR is zero because the
number of senders is less than the number of members.  Part of my
proposal was to remove the "senders > 0" term so that there isn't a
problem when there are no senders.

> This gets even worse if RTP retransmission is used (where different
> SSRCs might be used to multiplex media and retransmissions) as the
> bandwidth that one wants to dedicate to the receiver is actually
> shared equally between an increased number of SSRCs.

Yes, although not really equally because of the difference in packet
sizes.  But given the considerations I have outlined above, is it a
problem that we need to address?

> If changing the algorithm is too much of a change at this stage AND
> this shall not be solved by draft-ietf-avt-rtcp-bw-05.txt, then the
> only solution I see is to tell RTCP through SDP who uses which
> bandwidth values, but this needs also of another rtcp_interval()
> algorithm that accepts these values as parameters (as Magnus
> proposed in his code). Makes this sense to all?
>
> Would another draft be the rigth place for this other algorithm?
> Would that constitute a new profile?

A new profile could change the algorithm if that is necessary.  New
SDP parameters could be defined if that was necessary.  I suggest that
you guys run some numbers to see if it is a problem.

                                                        -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Sun, 15 Jun 2003 23:46:56 -0700 (PDT)

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

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.

                                                        -- Steve

---

From: "Jose Rey" <[email-masked]>
Date: Mon, 16 Jun 2003 13:32:00 +0200

Hi,

> 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

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.

> smooth transision that the existing algorithm was intended to
I see. I was referring more to the streaming unicast scenario. I guess my
characterization was not accure enough.

cheers,

Jose