Subject: [AVT] Non-compound RTCP

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 7 Feb 2007 10:05:04 +0100

Hi

A little before the new years party I posted an announcement of a new draft with the title 
"Support for non-compund RTCP in RTCP AVPF profile, opportunities and consequences", see abstract and link to draft below

Support for non-compound RTCP has since then been been presented for inclusion in a 3GPP specification (TS26.114). It was however delayed, the argument was mainly that this issue has not been discussed openly in IETF at all. So therefore opinons around this issue are very welcome, especially regarding: 

1) Examples where "middle boxes" in a network might discard non-compound RTCP. What kind of middle boxes are these.
2) Non-compound RTCP is specified in OMA-PoC (Push to talk). Are there any other standards or proprietary solutions or defacto standards that already today use non-compund RTCP and thus violate the rules outlined in RFC3550? Are there any problems ?

Regards
Ingemar

Abstract:
This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted as non-compound packets, i.e. not follow the rules of RFC 3550.  Based on that analysis this memo proposes changes to the rules to allow feedback messages to be sent as non-compound RTCP packets when using the RTP AVPF profile (RFC 4585)under certain conditions.
http://tools.ietf.org/wg/avt/draft-johansson-avt-rtcp-avpf-non-compound-00.txt

*******************************************
Ingemar Johansson
Senior Research Engineer
EAB/TVP - Multimedia Technologies Ericsson Research
Ericsson AB
Box 920
S-971 28 Luleå, Sweden
Tel: +46 (0)8 4043042
ECN: 850-43042
Mobile: +46 (0)730 783289
*******************************************

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

---

From: "Kalleitner, Franz" <[email-masked]>
Date: Wed, 7 Feb 2007 10:44:42 +0100

hi ingemar,

concerning MTSI: 
wouldn't it be sufficient to follow the 3GPP recommendation to keep the size of RTCP packets as small 
as possible. only to include SR or RR and SDES CNAME item (considering a short CNAME). Or do you refer to 
application dependent RTCP (RTCP-APP)? 

cheers,
franz

-----Ursprüngliche Nachricht-----
Von: Ingemar Johansson S (LU/EAB) [mailto:[email-masked]] 
Gesendet: Mittwoch, 07. Februar 2007 10:05
An: [email-masked]
Cc: Ingemar Johansson S (LU/EAB)
Betreff: [AVT] Non-compound RTCP

Hi

Regards
Ingemar

Abstract:

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Wed, 7 Feb 2007 15:04:52 +0100

Hi

This issue is debated to some extent in the draft 
http://tools.ietf.org/wg/avt/draft-johansson-avt-rtcp-avpf-non-compound-00.txt
Minimum compound RTCP will typically have a size in the order 80-90 bytes + IP/UDP header. This is with the SR and SDES CNAME items. If one wish to add adaptation signaling like described in 3GPP TS26.114 another extra 16 bytes is needed. 
In a 3GPP VoIP service these large RTCP packets are likely to face severe problems in terms of lost RTCP packets in bad coverage situations. This means that adaptation feedback runs a high risk of being nonfunctional in the cases where it is needed the most (namely bad channel conditions). The simple reason is that large packets will be segmented and therefore the loss probablity is increased.

The purpose of non-compound RTCP is to be able to transmit adaptation feedback like the one described in 3GPP TS26.114 more reliably. In the VoIP example these non-compound feedback packets are of the size 16bytes + IP/UDP which is considerably smaller than the ~100byte figure above.

Note 1: I have deliberately chosen to quote the figures without IP/UDP header, the simple reason is that header compression almost completely removes this overhead.

Note 2: The TS26.114 is available at 
http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-120.zip
The adaptation feedback is described in section 10.2

Regards
Ingemar 

> -----Original Message-----
> From: Kalleitner, Franz [mailto:[email-masked]] 
> Sent: den 7 februari 2007 10:45
> To: Ingemar Johansson S (LU/EAB)
> Cc: [email-masked]
> Subject: AW: [AVT] Non-compound RTCP
> 
> hi ingemar,
> 
> concerning MTSI: 
> wouldn't it be sufficient to follow the 3GPP recommendation 
> to keep the size of RTCP packets as small as possible. only 
> to include SR or RR and SDES CNAME item (considering a short 
> CNAME). Or do you refer to application dependent RTCP (RTCP-APP)? 
> 
> cheers,
> franz
> 
> Von: Ingemar Johansson S (LU/EAB) 
> [mailto:[email-masked]]
> A little before the new years party I posted an announcement 
> of a new draft with the title "Support for non-compund RTCP 
> in RTCP AVPF profile, opportunities and consequences", see 
> abstract and link to draft below
> 
> Support for non-compound RTCP has since then been been 
> presented for inclusion in a 3GPP specification (TS26.114). 
> It was however delayed, the argument was mainly that this 
> issue has not been discussed openly in IETF at all. So 
> therefore opinons around this issue are very welcome, 
> especially regarding: 
> 
> 1) Examples where "middle boxes" in a network might discard 
> non-compound RTCP. What kind of middle boxes are these.
> 2) Non-compound RTCP is specified in OMA-PoC (Push to talk). 
> Are there any other standards or proprietary solutions or 
> defacto standards that already today use non-compund RTCP and 
> thus violate the rules outlined in RFC3550? Are there any problems ?
> 
> Regards
> Ingemar
> 
> Abstract:
> This memo discusses benefits and issues that arise when 
> allowing RTCP packets to be transmitted as non-compound 
> packets, i.e. not follow the rules of RFC 3550.  Based on 
> that analysis this memo proposes changes to the rules to 
> allow feedback messages to be sent as non-compound RTCP 
> packets when using the RTP AVPF profile (RFC 4585)under 
> certain conditions.
> EAB/TVP - Multimedia Technologies Ericsson Research Ericsson 
> AB Box 920
> S-971 28 Luleå, Sweden
> Tel: +46 (0)8 4043042
> ECN: 850-43042

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 12 Feb 2007 14:08:53 -0800

Based on the meeting report:
Non-compound RTCP feature is *not* delayed in MTSI. It was not agreed for inclusion into the MTSI TS26.114. TS26.114 has already been approved without the non-compound RTCP feature.

Regards,
Hari
> From: Ingemar Johansson S (LU/EAB)
> Sent: Wednesday, February 07, 2007 1:05 AM
> To: [email-masked]
> Subject: [AVT] Non-compound RTCP
> 
> Hi
> 
> "Support for non-compund RTCP in RTCP AVPF profile, opportunities and
> consequences", see abstract and link to draft below
> 
> Support for non-compound RTCP has since then been been presented for
> inclusion in a 3GPP specification (TS26.114). It was however delayed, the
> argument was mainly that this issue has not been discussed openly in IETF
> at all. So therefore opinons around this issue are very welcome,
> especially regarding:
> 
> 1) Examples where "middle boxes" in a network might discard non-compound
> RTCP. What kind of middle boxes are these.
> 2) Non-compound RTCP is specified in OMA-PoC (Push to talk). Are there any
> other standards or proprietary solutions or defacto standards that already
> today use non-compund RTCP and thus violate the rules outlined in RFC3550?
> Are there any problems ?
> 
> Regards
> Ingemar
> 
> Abstract:
> This memo discusses benefits and issues that arise when allowing RTCP
> packets to be transmitted as non-compound packets, i.e. not follow the
> rules of RFC 3550.  Based on that analysis this memo proposes changes to
> the rules to allow feedback messages to be sent as non-compound RTCP
> packets when using the RTP AVPF profile (RFC 4585)under certain conditions.

---

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 13 Feb 2007 10:22:29 +0100

Hi

I was perhaps a little unclear in my selection of words (sorry)

The exact wording is found in section 9.9 of
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_42/Docs/S4-070177.zip 
See full text below. 

The main point was that it was not justified to delay the entire TS26.114 specification just because of the Non-compound RTCP feature. Instead Ericsson will submit a change request for next SA-4 meeting (Rennes April 23-27) containing more thorough argumentation for Non-compound RTCP.

Again the main argument against Non-compound RTCP was that it has been very little discussion about this topic in IETF. Therefore any comments on the draft 
http://tools.ietf.org/wg/avt/draft-johansson-avt-rtcp-avpf-non-compound-00.txt
are appreciated.

Regards
Ingemar

========== Text from the meeting notes ==========
Mr. Tomas Frankkila presented TD S4-070084 Non-compound RTCP, from Ericsson.
This document contained a proposal to recommend support for the use of non-compound RTCP in TS 26.114. The use of non-compound RTCP makes transmission of critical feedback messages more robust in severe radio conditions where small packet sizes are crucial for successful transmission, another advantage is that non-compound RTCP packets can be transmitted more frequently (since they are smaller). This means that adaptation requests can be transmitted more frequently with the given bandwidth, this enables faster adaptation. 
The concept is not new to the mobile industry; it is also used in OMA-PoC. 
The proposed change assumes an additional SDP attribute "ncp" interpreted as non-compound. Additionally the use of the parameter "trr-int" differs from what is described in ch. 7.3.2 in TS26.114.
The proposal to 3GPP-SA4 from Ericsson was to adopt these additions to the MTSI-TS.

Comments / Questions : Nokia expressed reservation on the proposed changes, despite OMA already accepted the concept proposed in the document. Also Siemens Networks was not in favour of the proposed changes. Ericsson proposed to continue eventually the discussion at next meeting, but felt more important that TS 26.114 is approved at SA#35.

Conclusion : the document was noted.
==================================================

> From: Desineni, Harikishan [mailto:[email-masked]] 
> Sent: den 12 februari 2007 23:09
> To: Ingemar Johansson S (LU/EAB); [email-masked]
> Subject: RE: [AVT] Non-compound RTCP
> 
> Non-compound RTCP feature is *not* delayed in MTSI. It was 
> not agreed for inclusion into the MTSI TS26.114. TS26.114 has 
> already been approved without the non-compound RTCP feature.
> 
> Regards,
> Hari
> > A little before the new years party I posted an 
> announcement of a new 
> > draft with the title "Support for non-compund RTCP in RTCP AVPF 
> > profile, opportunities and consequences", see abstract and link to 
> > draft below
> > 
> presented for 
> > inclusion in a 3GPP specification (TS26.114). It was 
> however delayed, 
> > the argument was mainly that this issue has not been 
> discussed openly 
> > in IETF at all. So therefore opinons around this issue are very 
> > welcome, especially regarding:
> > 
> > 2) Non-compound RTCP is specified in OMA-PoC (Push to 
> talk). Are there 
> > any other standards or proprietary solutions or defacto 
> standards that 
> > already today use non-compund RTCP and thus violate the 
> rules outlined in RFC3550?
> > Are there any problems ?
> > 
> > Regards
> > Ingemar
> > 
> > Abstract:
> allowing RTCP 
> > rules of RFC 3550.  Based on that analysis this memo 
> proposes changes 
> > to the rules to allow feedback messages to be sent as non-compound 
> > RTCP packets when using the RTP AVPF profile (RFC 
> 4585)under certain conditions.
> > 
> http://tools.ietf.org/wg/avt/draft-johansson-avt-rtcp-avpf-non-compoun
> > d-
> > 00.txt
> > 
> > EAB/TVP - Multimedia Technologies Ericsson Research Ericsson AB Box 
> > 920
> > S-971 28 Luleå, Sweden
> > Tel: +46 (0)8 4043042
> > ECN: 850-43042