Subject: Re: [AVT] Non-compound RTCP

From: <[email-masked]>
Date: Thu, 10 Apr 2008 13:41:56 +0200

In my understanding, as defined in RFC 4585 a FB message can contains more than one FCI field by the mean of the lenght field. Each FCI field contains a first SN lost plus up to 16 other losses in the BLP field that follow the first packet. So it can fit any burst loss length.
Am I wrong?

Gérard B.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de David R Oran
Envoyé : mercredi 9 avril 2008 23:44
À : Randell Jesup
Cc : Ingemar Johansson S; Colin Perkins; IETF AVT WG
Objet : Re: [AVT] Non-compound RTCP

A bit of food for thought:

A single RTCP NAK packet can NAK up to 16 RTP packets. In video, we see burst losses longer than this. Shouldn't the rules allow for multiple generic NAKs without also requiring the compound rules to include an RR?

DaveO.

On Apr 8, 2008, at 8:02 PM, Randell Jesup wrote:
> Colin Perkins <[email-masked]> writes:
>>> There is a potential risk with large non-compound RTCP that these
>>> packets may be lost in e.g highly optimized wireless links.   
>>> Therefore I
>>> wonder if there is a good idea to be able to negotiate this at 
>>> session setup.
>>
>> Seems reasonable.
>
> Yes, but only if this a) is useful enough (or trouble enough) to 
> enough people to be worthwhile, and b) we don't get in trouble with 
> people not
> (properly) implenting this part of the negotiation.  If the only 
> people who use the "single RTCP" mode are the 3G people, a lot of 
> other implementations will either not implement it, or if they do 
> won't have easy ways to test it.  Broken implementations can be even 
> more of a pain than non-implemented ones.
>
> I can see lots of people wanting to avoid the overhead of SR/RR.   
> The only
> people who really care about one-and-only-one RTCP are the 3G people.
> Since not everyone will implement this, they'll need to either live 
> with longer RTCPs from some (higher RTCP loss - this may be ok, or may 
> not), or use midboxes that split the RTCPs into multiple single RTCPs 
> anyways.  In that case, this draft still helps since the SR/RRs 
> wouldn't be there, and in almost all cases (outside of periodic SR/RR) 
> the remaining RTCP would be singular.
>
> All that said: I'm ok with it if people want that.
>
>>> In the present draft the use of non-compound RTCP is negotiated with 
>>> the SDP attribute "rtcp-nc", the idea is to extend this attribute 
>>> with the options a=rtcp-nc:single and a=rtcp-nc:multiple
>>>
>>> Where "single" means that the offerer can send only single non- 
>>> compound RTCP meaning that only one feedback meassage is put in each 
>>> lower layer datagram. "multiple" means that no such limitation 
>>> exist.
>
> "can only"?  I'd say "prefers" or some other such.  Since if the 
> answerer doesn't know about a=rtcp-nc at all, it will drop it and 
> assume compound RTCP, and the offerer needs to send (and receive) it 
> as compound.
>
>>> In the answer attribute is returned to the offerer.
>>>
>>> "a=rtcp-nc:single" is either returned as is (or removed if non- 
>>> compound RTCP is not supported).
>>>
>>> "a=rtcp-nc:multiple" is either returned as is (or removed if 
>>> non-compound RTCP is not supported).
>>>  This attribute can also be overridden to "a=rtcp-nc:single", if 
>>> this  occurs then the offerer MUST send single non-compound RTCP.
>
> That last statement confuses me.  Does this mean answering a=rtcp- 
> nc:multiple with a=rtcp-nc:single?  Does "MUST" here also refer to 
> periodic RTCPs with SR/RR?
>
>>> Comments to this ?
>>
>> Non-compound should probably mean exactly that: just one RTCP packet 
>> per lower layer datagram. Compound RTCP packets that don't follow the 
>> rules in RFC 3550 section 6.1 really need another name: they're not 
>> "non-compound" packets, but compound packets with differing 
>> composition.
>
> I agree the name no longer exactly matches the discussed ability.
>
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex- Amiga 
> OS team [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)
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: "Jose Rey" <[email-masked]>
Date: Thu, 10 Apr 2008 15:25:38 +0200

Gérard,

This is correct, the number of FCIs (bitmasks) is inferred using the "length" field:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|   FMT   |       PT      |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            Feedback Control Information (FCI)                 :
   :                                                               :

The RFC explicitly allows this option

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.

And later in 6.2.1 for Generic NACK:

   The FCI field MUST contain at least one and MAY contain more than one
   Generic NACK.

Cheers,

José 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, April 10, 2008 1:42 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [AVT] Non-compound RTCP
> 
> In my understanding, as defined in RFC 4585 a FB message can 
> contains more than one FCI field by the mean of the lenght 
> field. Each FCI field contains a first SN lost plus up to 16 
> other losses in the BLP field that follow the first packet. 
> So it can fit any burst loss length.
> Am I wrong?
> 
> Gérard B.
> 
> De : [email-masked] [mailto:[email-masked]] De la 
> part de David R Oran Envoyé : mercredi 9 avril 2008 23:44 À : 
> Randell Jesup Cc : Ingemar Johansson S; Colin Perkins; IETF 
> AVT WG Objet : Re: [AVT] Non-compound RTCP
> 
> A single RTCP NAK packet can NAK up to 16 RTP packets. In 
> video, we see burst losses longer than this. Shouldn't the 
> rules allow for multiple generic NAKs without also requiring 
> the compound rules to include an RR?
> 
> DaveO.
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke