Re: [AVT] (no subject)

[David R Oran <oran at cisco.com>]

On Mar 11, 2008, at 6:30 PM, Ingemar Johansson S wrote:

> Hi
>
> As a follow up from todays discussion just in order to "cast the  
> iron while it's hot"
>
> I can see that there are essentially two options regarding what  
> constitutes a non-compound RTCP
> 1) One RTCP / UDP
> 2) RTCP that deviate from the SR/RR + SDES rules.
>
2 is much more useful than 1, especially for feedback on high-rate  
video where the occurrence a burst loss of more than 16 packets is  
quite likely.

> 1) is quite strict in that it only specifies one RTCP / UDP, quite a  
> simple approach but may be limited in certain situations.
> 2) Essentially says that anything that is not SR+SDES(CNAME) or RR 
> +SDES(CNAME)  is a non-compound RTCP. This makes it possible to  
> stack several feedback messages on top of one another.
>
I have a storng preference for (2).

> If one would follow 2) one could actually envision an "imaginary"  
> rewrite of RFC4585 section 3.1 in line with the below:
>
> =====================
> a) Minimal compound RTCP feedback packet
> ...
> ......
> .....
> b) (Full) compound RTCP feedback packet
> ...
> ......
> .....
> (c) Non-compound RTCP feedback packet
> A non-compound RTCP does not (generally) contain the items specified  
> in a) for a Minimal compound RTCP. A Non-compound RTCP can be used  
> to convey one or more feedback (or control) messages with the sole  
> purpose to minimize the RTCP overhead associated with the RR, SR and  
> SDES RTCP packet types. Although more than one feedback message can  
> be conveyed in a non-compound RTCP it is still RECOMMENDED to keep  
> the size of non-compound RTCP as small as possible with a preference  
> for single feedback messages in non-compound RTCPs.
> =====================
> More text is needed, esp. regarding enforcing RTCP of type a) above  
> and also regarding the possiblility to do some minimal verification  
> of middle box behavior using non-compound SR and R.
> The text above is just sort of an initial "bait". Version 1) above  
> (1 RTCP/UDP) would lead to a more strict wording in the imaginary  
> text above.
> Personally I am more in favor or version 2) above as it is more in  
> line with how the feedback messages can be stacked in RFC4585 and in  
> the codec control messages draft... with the disclaimer that single  
> messages are preferred.
>
The words "single messages are to be preferred" could mean that you  
prefer to have only 1 RTCP packet per UDP packet, or that you prefer  
to have as many RTCP packets per UDP packet as you can given space and  
timing constraints. I certainly hope you mean the latter.

DaveO.


> Comments are very welcome.
> /Ingemar
>
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVP - Multimedia Technologies
>  Ericsson Research Ericsson AB
>  Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)8 4043042
> ECN: 850-43042
> ECC: 850-43074
> Mobile: +46 (0)730 783289
> *******************************************
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt

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