Subject: [AVT] Question regarding draft-ietf-avt-rtcp-bw-05.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Sep 2002 13:40:22 +0200

Steve,

I have a question regarding the interpretation of  the SDP Bandwidth 
Modifiers for RTCP Bandwidth. Shall lower layer (IP/UDP) also be 
included in the calculation of the bandwidth modifiers RR and RS? This 
should be clarified and as it is in the RFC editors queue I guess it 
still possible to do such a clarification.

I would also like to argue that although including the lower layer in 
the bandwidth makes it obvious how much one needs to reserve and will in 
fact be used on average for the RTCP traffic it has disadvantages. In 
cases where one has traffic going from IPv6 networks to IPv4 the actual 
useful reporting bandwidth will be different depending if a host has 
IPv6 or IPv4. It will also result in that the RTCP bandwidth for the 
IPv6 host will be overshot. How much is dependent on the number of RTCP 
packets coming from the IPv4 domain.

If one would not include lower layers in the value it would be hard to 
calculate the exact amount that will be used on the network, seen from 
any receiver's view point as it will depend on the rate of RTCP packets. 
This however can be estimated based on the given bandwidth and the 
average size of RTCP packets. The average packet size depends on for 
example what packet types an application needs. To simplify such 
calculation one could define a new bandwidth modifier or an attribute 
giving the initial RTCP packet size. The advantage of not including the 
lower layers is that all receivers has the same possibilities to report.

I am working on a draft that tries to address this problem for the RTP 
data traffic.

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: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Sep 2002 13:36:44 +0200

Hi again,

I have considered these problems a bit further and have some conclusions 
to share with you.

First, it seems necessary to include lower layers in the RTCP bitrate 
parameter. This depending on how the algorithm using this bandwidth 
number works. The algorithm could of course be changed easily to 
calculate without lower layers. However such a change would result in an 
even more unclear situation on how much bandwidth would be used over a 
connection. The most important parameters controlling how many RTCP 
packets are sent each second is the average RTCP packet size and the 
bandwidth assigned to RTCP.

It would be rather easy to calculate a packet rate if the average RTCP 
packet size was known. However this value depends on the application and 
what it sends with RTCP. It changes over time in a session, due to 
changed network situation, number of participants, or an applications 
mode of operation. Therefore it would be very difficult to get any 
static parameters that are good enough and which would result in less 
errors than the actual change of overhead result in.

Still I think it is desirable to try to prevent that the used RTCP 
bandwidth overshoot the given value with as much as 20-25 % when going 
from an IPv4 to an IPv6 host. In this case I think under utilization in 
the IPv4 network is a better alternative. Therefore I would recommend 
that the RR and RS values is used as if they include overhead for 
IPv6/UDP or IPv6 and the used transport layer. If also IPv4 hosts uses 
RTCP avg_RTCP_size parameters that include IPv6 overhead and calculate 
their own overhead as IPv6, no overutilization will occur in native IPv6 
networks. Unfortunately such a solution can still in some cases result 
in overutilization. For example in the case that IPv6 traffic is 
tunneled over IPv4, one would have even bigger overhead. Hopefully when 
running tunnels, one ensures a certain overprovisining to ensure that 
the tunnel overhead does not create problems. Can anyone give some 
insight into this?

So the problem could basically be solved if one knows if any 
participants are IPv6 hosts. Unfortunately there exist scenarios when 
the different parties in a session does not know if the other 
participants is running IPv6 or not. Shall one as a basic precaution 
always calculate with IPv6 overhead?

So I would suggest that one a little bit clearer than referencing the 
RTP spec says that the RTCP bandwidth given by RR and RS includes lower 
layers as well. On the issue of resolving the problem I don't have a 
good solution, suggestions are happily received.

Regards

Magnus

Magnus Westerlund wrote:

> the bandwidth makes it obvious how much one needs to reserve and will 
> in fact be used on average for the RTCP traffic it has disadvantages. 
> In cases where one has traffic going from IPv6 networks to IPv4 the 
> actual useful reporting bandwidth will be different depending if a 
> host has IPv6 or IPv4. It will also result in that the RTCP bandwidth 
> for the IPv6 host will be overshot. How much is dependent on the 
> number of RTCP packets coming from the IPv4 domain.
>
> any receiver's view point as it will depend on the rate of RTCP 
> packets. This however can be estimated based on the given bandwidth 
> and the average size of RTCP packets. The average packet size depends 
> on for example what packet types an application needs. To simplify 
> such calculation one could define a new bandwidth modifier or an 
> attribute giving the initial RTCP packet size. The advantage of not 
> including the lower layers is that all receivers has the same 
> possibilities to report.
>

-- 

Magnus Westerlund