Subject: Re: [AVT] Non-compound RTCP (draft-ietf-avt-rtcp-non-compound-01)

From: Colin Perkins <[email-masked]>
Date: Sat, 1 Dec 2007 14:49:07 +0000

Hi Ingemar,

On 27 Nov 2007, at 08:07, Ingemar Johansson S wrote:
> Due to a series of unfortunate events it seems like the update of  
> the Non-compound RTCP draft (now a wg item) did not make its way to  
> tools.ietf.org/wg/avt
>
> Because of this I feel that I need to post the draft like this.

Please resubmit this unchanged after the meeting, if your original  
submission doesn't appear.

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

I like the discussion of use cases here, and do think the approach of  
sending non-compound RTCP packets has merit. Some comments on the  
details:

Section 6.1: Is it possible to outline algorithms for detecting if  
non-compound RTCP packets are received for the currently standardised  
uses of RTCP? Providing some guidance to application authors would be  
valuable.

Section 6.1 (last paragraph): "strongly recommended" -> "strongly  
RECOMMENDED"

Section 6.2: There's a lot of complexity in the modified algorithm  
for assigning bandwidth to non-compound RTCP packets. It's not clear  
this is warranted, since the avg_rtcp_size already includes the lower- 
layer headers, and so encourages transmission of larger packets  
(since more useful data is sent). I guess this will be one of the  
main points for discussion in Vancouver.

Section 6.2: A simple way to distinguish compound and non-compound  
RTCP packets is to compare the length of the first RTCP packet with  
the length of the lower layer packet in which it is delivered. If the  
RTCP packet is shorter, this is a compound RTCP packets.

Section 6.3: need to properly register the new SDP attribute,  
following the form in RFC 4566. I suggest using "a=rtcp-nc" rather  
than "a=ncp" to be more obvious, and to match the "a=rtcp-mux"  
attribute. An offer/answer considerations section also need to be added.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Sun, 2 Dec 2007 20:52:17 +0100

Hi

A few comments to the complexity comment regarding section 6.2. 
Regarding implementation complexity: When the proposed algorithm changes
are applied to the OnExpire pseudo-code in appendix A of RF3550 the code
code size increases ~100% (comments included). I would regard the
computational complexity increase to be quite modest. 
It is of course possible that more stuff needs to be added to avoid
potential issues with feedback implosions and other issues that are
listed.
A note: The pseudocode modifications was not included in the draft as we
(me and Magnus Westerlund) deemed that that was a little bit to early to
include it, we preferred to take a half step back to get an opinion from
others regarding  basic idea.

Regards
Ingemar
> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: den 1 december 2007 06:49
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [AVT] Non-compound RTCP 
> (draft-ietf-avt-rtcp-non-compound-01)
> 
> Hi Ingemar,
> 
> > Due to a series of unfortunate events it seems like the 
> update of the 
> > Non-compound RTCP draft (now a wg item) did not make its way to 
> > tools.ietf.org/wg/avt
> >
> Please resubmit this unchanged after the meeting, if your 
> original submission doesn't appear.
> 
> > Abstract
> > ==================
> >    packets to be transmitted as non-compound packets, i.e 
> not follow 
> > the
> I like the discussion of use cases here, and do think the 
> approach of sending non-compound RTCP packets has merit. Some 
> comments on the
> details:
> 
> Section 6.1: Is it possible to outline algorithms for 
> detecting if non-compound RTCP packets are received for the 
> currently standardised uses of RTCP? Providing some guidance 
> to application authors would be valuable.
> 
> Section 6.1 (last paragraph): "strongly recommended" -> 
> "strongly RECOMMENDED"
> 
> Section 6.2: There's a lot of complexity in the modified 
> algorithm for assigning bandwidth to non-compound RTCP 
> packets. It's not clear this is warranted, since the 
> avg_rtcp_size already includes the lower- layer headers, and 
> so encourages transmission of larger packets (since more 
> useful data is sent). I guess this will be one of the main 
> points for discussion in Vancouver.
> 
> Section 6.2: A simple way to distinguish compound and 
> non-compound RTCP packets is to compare the length of the 
> first RTCP packet with the length of the lower layer packet 
> in which it is delivered. If the RTCP packet is shorter, this 
> is a compound RTCP packets.
> 
> following the form in RFC 4566. I suggest using "a=rtcp-nc" 
> rather than "a=ncp" to be more obvious, and to match the 
> "a=rtcp-mux"

---

From: Stephen Casner <[email-masked]>
Date: Sun, 2 Dec 2007 13:54:35 -0800 (PST)

Colin,

I've not been tracking the AVT activity closely, but all the comments
you've made in this set of recent messages seem right on point to me.

Dec  2 Colin Perkins   Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-video-02.txt
Dec  2 Colin Perkins   Re: [AVT] I-D ACTION:draft-ietf-avt-rtcphr-02.txt
Dec  1 Colin Perkins   Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-svc-03.txt
Dec  2 Colin Perkins   Re: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-audio-01.txt
Dec  1 Colin Perkins   Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-svc-03.txt
Dec  1 Colin Perkins   Re: [AVT] Non-compound RTCP (draft-ietf-avt-rtcp-non-compound-01)

We may have some interesting discussions here in Vancouver.

                                                        -- Steve