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

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 11 Feb 2008 08:31:55 +0100

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 <[email-masked]>
>Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound-02.txt
>To: AVT WG <[email-masked]>
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

>On 8 Feb 2008, at 23:45, [email-masked] 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
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Feb 2008 10:43:09 -0500

>cause for SRTP so if anybody has info regarding this I would be very

SRTP/SRTCP should be unaffected by this change.  

>packet but rejects all other types of non-compound RTCP.

It does sound useful.

>one RTCP, no matter the type, this would simply the discrimination.

That sounds reasonable to me (since the restriction we're trying to relax
is the "must have SR/RR plus one other" rule).  The other bullet points
sound mostly like heuristics to *guess* whether it's non-compound without
actually looking at what's in it - an odd thing to do, IMHO.  The sole
exception would be if you need to know if it's a non-compound SRTCP packet
*without* decrypting it (since only the length of the first packet is in
the clear.  Why you'd want to know that, I don't know.

Note: the "size of first RTCP sub-packet plus overhead == UDP packet size"
test is NOT correct unless you also account for SRTCP overhead.  If you
want to keep that description, please add some phrase about including
SRTCP overhead (which may vary depending on what was negotiated for tag
length and optional MKI).

Note that section 9.1 of RFC 3550 will be affected by this change, though
I don't think that will be any problem.  It may be worth mentioning.

-- 
Randell Jesup
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)