[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Non-compound RTCP (Was RE: (no subject))
Hi
Comments inline below
/Ingemar
> -----Original Message-----
> From: David R Oran [mailto:oran at cisco.com]
> Sent: den 11 mars 2008 18:38
> To: Ingemar Johansson S
> Cc: avt at ietf.org
> Subject: Re: [AVT] (no subject)
>
>
> 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.
Sorry for the very weak formulation, actually I my preference is for single messages in each RTCP with the purpose to keep the total size of the non-compound RTCP as small as possible. The reasons behind this preference is to be found in section 3 in
http://tools.ietf.org/html/draft-ietf-avt-rtcp-non-compound-03
That said, I am not a very religious guy, I believe that it may be possible to allow for multiple messages in a non-compound RTCP but then one must keep in mind that the whole idea with non-compound RTCP diminishes as the size ratio between compound and non-componud RTCP decreases with the number of feedback messages.
>
> 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