Re: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound-02.txt

["Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>]

Hi

The observant reader might notice that the more advanced bandwidth
computation algorithms given in the previous draft has been removed in
the updated draft. A motivation to this is given in the draft text. I
have tried to find out what kinds of issues that non-compound RTCP might
cause for SRTP so if anybody has info regarding this I would be very
grateful.

Comments to Colin's comments inline. 

>Message: 4
>Date: Sun, 10 Feb 2008 11:07:49 +0000
>From: Colin Perkins <csp at csperkins.org>
>Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound-02.txt
>To: AVT WG <avt at ietf.org>
>Message-ID: <B9723C30-82B3-46AF-B24C-463F7F390129 at csperkins.org>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

>On 8 Feb 2008, at 23:45, Internet-Drafts at ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Audio/Video Transport Working  
>> Group of the IETF.
>>
>> 	Title		: Support for non-compound RTCP, opportunities
and  
>> consequences
>> 	Author(s)	: I. Johansson, M. Westerlund
>> 	Filename	: draft-ietf-avt-rtcp-non-compound-02.txt
>> 	Pages		: 16
>> 	Date		: 2008-2-8
>> 	
>> 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.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-non- 
>> compound-02.txt

>While I haven't had chance to read the analysis of the algorithmic  
>changes, I have two comments on the other details:

>Section 6.1: a simple test that non-compound packets are not rejected  
>out-of-hand might be to send a non-compound SR packet, then check  
>that the timestamp is echoed back in the corresponding RR packet?
A first glance this sounds like a neat solution. It may not cover the
exotic case that a middle box accepts non-compound RTCP with only SR
packet but rejects all other types of non-compound RTCP.

>Section 6.2.1: the first four bullet points are unnecessary, since  
>non-compound packets can be detected by comparing their size with the  
>size of the containing transport layer packet.
I guess this boils down to what the exact definition of what a
non-compound RTCP is. If the non-compound RTCP contains only one RTCP,
then you are right. However the current definition in the draft is that
a non-compound RTCP is one that deviates from the minimum (or full)
compound RTCP rules in RFC3550. Perhaps the only wise thing is to narrow
down the definiton such that a non-compound RTCP is one that contains
one RTCP, no matter the type, this would simply the discrimination.

/Ingemar





_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt