Re: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation

["Miguel A. Garcia" <[e-mail]>]

Hi,

Many thanks to Magnus and Roni for discussing the wording of this LS 
resposne. This is to close the discussion on this topic.

There is general agreement on the LS. I believe Roni ask to add a 
reference to RFC 3556 in our bullet point #3.

This is the final response that we will be forwarding to 3GPP SA4.

/Miguel

==========

Source: IETF MMUSIC WG
To: 3GPP TSG SA WG4 (SA4)

Title: Reply regarding On RTCP Bandwidth Negotiation


MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
SA4's identification that there exist no well defined behavior for the
negotiation of the RTCP bandwidth parameters RR and RS when used in
Offer/Answer context to negotiate a unicast transported RTP session. It
is clear that the RTP session participating end-points do need to agree
on common values or there exist a potential for interoperability failures.

Regarding the proposed recommendations for negotiation MMUSIC WG has the
following comments.

1. Based on the limitations of Offer/Answer and the requirement on
arriving at a common RTCP bandwidth value for RR and RS respectively
there exist only two possible choices. A. that the Offerer dictates the
bandwidth values without any possibilities for B to change the values,
or B. as proposed in the LS that the Offerer suggest a value that
the Answerer may modify. On that high level MMUSIC WG considers the
proposed solution appropriate

2. However, we do consider the limitation that the answerer only can
keep or reduce the bandwidth values to a be a potential issue in the
proposed recommendation. The reason is that the answering party then
have no way of increasing the value if the peer agent is not willing to
accept the higher suggested values in a subsequent Offer. This may
appear a reasonable behavior in many cases and considering limited total
bandwidth on the path between the agents. However, when an agent
requires a higher RTCP bandwidth due to its usage of some RTCP based
extensions this could prevent such functionality from being used. And
the bandwidth usage could be addressed by having the answering party to
reduce the total RTP session bandwidth in its answer and be forced to
reduce the bit-rate delivered to the other agent in proportion to the
increase of the RTCP bandwidth.

3. Has any special consideration been taken around the usage of RR or RS
parameter values of 0 as specified in RFC 3556? If either offerer or 
answerer intended to turn off RTCP completely or for receivers only, it 
is questionable that this should have precedence over the other agents 
desire to use RTCP.

MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
rules for the RR and RS bandwidth parameters. This would be to provide
all users of the RTCP bandwidth parameter with guidance on this issue.
If the participants in SA4 WG considers that appropriate, MMUSIC WG
would highly appreciate any engagement from the SA4 participants in
the MMUSIC WG.


=========

On 01/08/2012 21:36, Miguel A. Garcia wrote:
> A reminder to the WG.
>
> We indicated earlier in the meeting that we have only 2 additional days
> for commenting Magnus'es proposed answer to this LS. We are aiming to get
> an agreed response by this Friday August 3rd.
>
> /Miguel
>
> On 01/08/2012 3:35, Magnus Westerlund wrote:
>> MMUSIC WG,
>>
>> Below you find my proposal for a reply to the LS we received from 3GPP
>> SA4 WG.
>> https://datatracker.ietf.org/liaison/1159/
>>
>> This is intended as a starting point for a discussion of what reply we
>> as WG want to send. So please review it and send comments on this.
>>
>> I would highly appreciate any insights how this issues is currently
>> dealt with in any implementations. If we have knowledge of multiple
>> different solutions then that is something we should indicate. Also if
>> any existing solution clashes with SA4's proposed solution.
>>
>> I also raise the question if we should initiate any update of RFC 3556.
>> And if we can come to such an agreement and have volunteers we may be
>> able to strengthen the language in the last paragraph. Otherwise that
>> language is intended to signal a preference for the driving parties in
>> SA4 to come help us update the RFC in MMUSIC WG.
>>
>> ===
>> Source: IETF MMUSIC WG
>> To: 3GPP TSG SA WG4 (SA4)
>>
>> Title: Reply regarding On RTCP Bandwidth Negotiation
>>
>>
>> MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with
>> SA4's identification that there exist no well defined behavior for the
>> negotiation of the RTCP bandwidth parameters RR and RS when used in
>> Offer/Answer context to negotiate a unicast transported RTP session. It
>> is clear that the RTP session participating end-points do need to agree
>> on common values or there exist a potential for interoperability failures.
>>
>> Regarding the proposed recommendations for negotiation MMUSIC WG has the
>> following comments.
>>
>> 1. Based on the limitations of Offer/Answer and the requirement on
>> arriving at a common RTCP bandwidth value for RR and RS respectively
>> there exist only two possible choices. A. that the Offerer dictates the
>> bandwidth values without any possibilities for B to change the values,
>> or B. as proposed in the LS that the Offerer suggest a value that
>> the Answerer may modify. On that high level MMUSIC WG considers the
>> proposed solution appropriate
>>
>> 2. However, we do consider the limitation that the answerer only can
>> keep or reduce the bandwidth values to a be a potential issue in the
>> proposed recommendation. The reason is that the answering party then
>> have no way of increasing the value if the peer agent is not willing to
>> accept the higher suggested values in a subsequent Offer. This may
>> appear a reasonable behavior in many cases and considering limited total
>> bandwidth on the path between the agents. However, when an agent
>> requires a higher RTCP bandwidth due to its usage of some RTCP based
>> extensions this could prevent such functionality from being used. And
>> the bandwidth usage could be addressed by having the answering party to
>> reduce the total RTP session bandwidth in its answer and be forced to
>> reduce the bit-rate delivered to the other agent in proportion to the
>> increase of the RTCP bandwidth.
>>
>> 3. Has any special consideration been taken around the usage of RR or RS
>> parameter values of 0. If either offerer or answerer intended to turn
>> off RTCP completely or for receivers only, it is questionable that this
>> should have precedence over the other agents desire to use RTCP.
>>
>> MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer
>> rules for the RR and RS bandwidth parameters. This would be to provide
>> all users of the RTCP bandwidth parameter with guidance on this issue.
>> If the participants in SA4 WG considers that appropriate, MMUSIC WG
>> would highly appreciate any engagement from the SA4 participants in
>> the MMUSIC WG.
>>
>> Actions: None
>>
>> -- end of proposed LS reply --
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain