Subject: Re: [AVT] Non-compound RTCP

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 3 Apr 2008 09:53:21 +0200

Hi

As a followup on the discussion regarding large and small non-compound
RTCP.

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.

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.

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.

Comments to this ?

/Ingemar

----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Mar 2008 22:37:55 +0100
From: "Ingemar Johansson S" <[email-masked]>
Subject: Re: [AVT] Non-compound RTCP
To: "Randell Jesup" <[email-masked]>
Cc: David R Oran <[email-masked]>, [email-masked]
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain;	charset="US-ASCII"

Hi

In order to satisfy as many use cases as possible one could use e.g an
extra SDP attribute along with the "rtcp-nc" attribute that specifies
whether non-compound should be limited to single RTCP / UDP or if it
should be possible to stack several RTCP feedback messages in one UDP.
The latter of course deviates from original intent. 
To avoid that large non-compound RTCP steals too much bandwidth from
regular compound RTCP there must be put a limit somewhere anyway to how
large a non-compound RTCP should be allowed to be before being forced to
be a compound RTCP. I believe that such a requirement is reasonable as
it is still possible to send compound RTCP timely using AVPF Early mode.

Thanks for the feedback sofar
/Ingemar

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]]
> Sent: den 12 mars 2008 19:17
> To: Ingemar Johansson S
> Cc: David R Oran; [email-masked]
> Subject: Re: [AVT] Non-compound RTCP
> 
> "Ingemar Johansson S" <[email-masked]> writes:
> >I guess there is a preference to allow for mutiple messages
> and I guess
> >I can live with this, however with some disclaimer that
> small feedback
> >packets are to be preferred atleast in the "wireless optimized radio 
> >bearer world" that I come from. Guess that this preference does not 
> >apply to all usage scenarios and access types.
> 
> Right - we're providing a mechanism that can be used for a few 
> different things; one of which is keeping feedback RTCPs below a 
> radio-relevant size threshold.  To an extent, this preference is 
> application/usage-specific.
> 
> >One problem is maybe that as applications should preferrably
> not care
> >about the access type, problems may arise if large feedback packets 
> >from eg. a UA connected to a wireline access enter a system that is 
> >optimized for transmission of small packets (e.g 3GPP HSPA optimized 
> >for VoIP). In the latter wireless system there is a potenial
> risk that
> >the feedback is lost due to eg lower layer fragmentation and the 
> >following increased sensitivity to poor channel conditions.
> >The scenario above is one of the main reasons to why this
> non-compound
> >RTCP stuff was brought up.
> 
> This defines the mechanism where you can send non-compound RTCP (and 
> would allow as well for smaller compound RTCPs).
> Deciding when to do so and in what manner is an issue more for 
> application layer and signalling.
> The case of a UA on wireline sending larger packets is an issue 
> regardless of whether non-compound is available.  You can inform the 
> other side as to your preference via signalling, or not.
> 
> Defining this standard with only single RTCPs allowed (without an 
> SR/RR) will just mean that those wireline devices that have two RTCPs 
> to send will include an SR/RR as well.
> They probably wouldn't send them as two single non-compound RTCPs, 
> unless they were designed with communication to a radio device, or 
> unless they were given a hint through signalling.
> 
> A network element in theory (for non-encrypted RTCP) could split a 
> compound RTCP (with or without RR/SR) into multiple 
> single/non-compound RTCP packets.  I probably wouldn't recommend it - 
> there are complexities hidden in that simple description - but you 
> could.
> 
> --
> 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)
> 
> 

------------------------------

Message: 2
Date: Thu, 13 Mar 2008 18:33:07 -0400
From: Randell Jesup <[email-masked]>
Subject: Re: [AVT] Non-compound RTCP
To: "Ingemar Johansson S" <[email-masked]>
Cc: David R Oran <[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

"Ingemar Johansson S" <[email-masked]> writes:
>In order to satisfy as many use cases as possible one could use e.g an
>extra SDP attribute along with the "rtcp-nc" attribute that specifies
>whether non-compound should be limited to single RTCP / UDP or if it
>should be possible to stack several RTCP feedback messages in one UDP.
>The latter of course deviates from original intent. 

Restating assumptions to make sure we're on the same page:

The original intent was to (if I'm correctly remembering) reduce the
size of feedback RTCPs such that they'd be less likely to be lost on a
3GPP/whatever radio link.  (And probably also use less bandwidth, but I
think that was secondary at best.)

The problem with normal compound (SR/RR) RTCP was that all RTCPs end up
bumped over the specific limit you're dealing with.

The the fundamental issue was size, and the non-compound draft (removing
SR/RR/etc) was a way to get around that problem most of the time by
eliminating redundant/minimally-useful information (SR/RR/etc), when
it isn't needed.

So the goal is reduced size, and the mechanism proposed is to remove 
redundant information.  What worries you is that other non-redundant 
information (multiple useful RTCPs) might bump you back over that limit.

What you really want is to continue to stay inside that size limit.  I
don't think you really object to getting more useful information in the
packet, so long as it doesn't significantly increase the chance of loss.

If it's not critical or only a minor issue at times, we could just 
define it as one or more RTCP 'packets' with no leading SR/RR.

If this was a critical requirement, we could implement something like
that
(or a parameter to a=rtcp-nc that specifies the number of RTCPs allowed
in a non-SR/RR packet, or a parameter that specifies the size break you
want the sender to stay below, etc).  How critical is it in practice?
Realize that most of the time, early feedback packets aren't held a pile
up
waiting to be sent - they're normally sent immediately or at least
before a
second one is generated.  In this case, they'd be sent alone anyways.

Or, of course, if it's critical we could simply limit non-compound RTCP
to
a single RTCP item. (I *hate* the term packet in this discussion because
you always end up having to qualify it, and "RTCP packet" could mean one
item ("packet"), or one (possibly) compound (UDP) RTCP packet.)  This
would
impose some occasional extra overhead, but again (per above) I don't
think
this will happen all that often, so the extra overhead for multiple
packets
isn't a big deal.

So, if (you believe) it's important to your or other significant
applications *in practice*, then I'd be ok with limiting it to one RTCP
"packet".  If so, you should *suggest* that senders with multiple
feedback
packets to send send multiple UDP packets, and not send an even larger
compound RTCP with SR/RR.

>To avoid that large non-compound RTCP steals too much bandwidth from
>regular compound RTCP there must be put a limit somewhere anyway to how
>large a non-compound RTCP should be allowed to be before being forced
to
>be a compound RTCP. I believe that such a requirement is reasonable as
>it is still possible to send compound RTCP timely using AVPF Early
mode.
>
>Thanks for the feedback sofar
>/Ingemar
>
>
>> -----Original Message-----
>> From: Randell Jesup [mailto:[email-masked]] 
>> Sent: den 12 mars 2008 19:17
>> To: Ingemar Johansson S
>> Cc: David R Oran; [email-masked]
>> Subject: Re: [AVT] Non-compound RTCP
>> 
>> "Ingemar Johansson S" <[email-masked]> writes:
>> >I guess there is a preference to allow for mutiple messages 
>> and I guess 
>> >I can live with this, however with some disclaimer that 
>> small feedback 
>> >packets are to be preferred atleast in the "wireless optimized radio

>> >bearer world" that I come from. Guess that this preference does not 
>> >apply to all usage scenarios and access types.
>> 
>> Right - we're providing a mechanism that can be used for a 
>> few different things; one of which is keeping feedback RTCPs 
>> below a radio-relevant size threshold.  To an extent, this 
>> preference is application/usage-specific.
>> 
>> >One problem is maybe that as applications should preferrably 
>> not care 
>> >about the access type, problems may arise if large feedback packets 
>> >from eg. a UA connected to a wireline access enter a system that is 
>> >optimized for transmission of small packets (e.g 3GPP HSPA optimized

>> >for VoIP). In the latter wireless system there is a potenial 
>> risk that 
>> >the feedback is lost due to eg lower layer fragmentation and the 
>> >following increased sensitivity to poor channel conditions.
>> >The scenario above is one of the main reasons to why this 
>> non-compound 
>> >RTCP stuff was brought up.
>> 
>> This defines the mechanism where you can send non-compound 
>> RTCP (and would allow as well for smaller compound RTCPs).  
>> Deciding when to do so and in what manner is an issue more 
>> for application layer and signalling.  
>> The case of a UA on wireline sending larger packets is an 
>> issue regardless of whether non-compound is available.  You 
>> can inform the other side as to your preference via 
>> signalling, or not. 
>> 
>> Defining this standard with only single RTCPs allowed 
>> (without an SR/RR) will just mean that those wireline devices 
>> that have two RTCPs to send will include an SR/RR as well.  
>> They probably wouldn't send them as two single non-compound 
>> RTCPs, unless they were designed with communication to a 
>> radio device, or unless they were given a hint through signalling.
>> 
>> A network element in theory (for non-encrypted RTCP) could 
>> split a compound RTCP (with or without RR/SR) into multiple 
>> single/non-compound RTCP packets.  I probably wouldn't 
>> recommend it - there are complexities hidden in that simple 
>> description - but you could.
>> 
>> --
>> 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)
>> 
>> 

-- 
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

End of avt Digest, Vol 47, Issue 15
***********************************
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Thu, 3 Apr 2008 08:13:25 -0400

>  offerer MUST send single non-compound RTCP.
Two quick comments:
1) I'm not sure how you would in practice choose between the two. If  
we do go down the road of signaling, I think a better idea might be to  
specify a maximum RTCP packet size for RTCP packets intended to be  
covered by the rules in the the non-compound-rtcp (now a misnomer)  
draft.
2) don't forget the non offer-answer scenarios, like multicast video.

> < 
> [email-masked]>
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 Apr 2008 22:02:36 +0100

Hi,

> wonder if there is a good idea to be able to negotiate this at session

Seems reasonable.

>   offerer MUST send single non-compound RTCP.

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.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Tue, 08 Apr 2008 20:02:38 -0400

>> wonder if there is a good idea to be able to negotiate this at session

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.  

>> Where "single" means that the offerer can send only single non- compound

"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.

>> "a=rtcp-nc:single" is either returned as is (or removed if non- compound
>> RTCP is not supported).
>>
>>   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?

>"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)

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 9 Apr 2008 08:16:52 +0200

Hi

I am currently rewriting the draft and from the discussion sofar I get a
feeling that there is a rough 2(or 3) against 1 vote in favor of making
things as simple as possible. In other words, no single vs multiple
negotiation and I will likely go for the simple solution in the next
update of the draft. 

Besides this the multiple messages in a lower layer datagram is a bit
trycky to manage, it essentially goes against all the initial motivation
for the non-compound draft and as such is diffucult to cram into the
draft without making the whole thing look silly. Hopefully the next
update of the draft will manage to avoid this.

Thanks for the feedback !

/Ingemar

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: den 9 april 2008 02:03
To: Colin Perkins
Cc: Ingemar Johansson S; IETF AVT WG
Subject: Re: [AVT] Non-compound RTCP

Colin Perkins <[email-masked]> writes:
>> 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.

>> 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.

>> "a=rtcp-nc:single" is either returned as is (or removed if non- 
>> compound RTCP is not supported).
>>

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?

--
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)

---

From: Randell Jesup <[email-masked]>
Date: Wed, 09 Apr 2008 11:41:22 -0400

>negotiation and I will likely go for the simple solution in the next

Ok.  I'd thought that the consensus at IETF 71 was for including
"RTCP-without-RR/SR", but that isn't binding of course.

>update of the draft will manage to avoid this.

I realize that the main motivation for a draft was the radio packet size
issues, but a secondary motivation (for people like me) is to reduce RTCP
bandwidth use, especially when using a lot of AVPF feedback and codec
control messages.  (A useful side-effect is lower average feedback sizes
means more feedback is possible without having to hold it off.) In those
cases it's possible that a strict 1-message-per-UDP-packet rule could lose
some of the advantage gained by dropping RR/SR.

There are similar but not fully compatible goals here.  We need to either
make something that deals with both goals (like the single/multiple stuff)
with some added complexity (and maybe that's ok, especially if it's easy to
test), or make a single solution that isn't optimal for one side.  Either
extra bandwidth use in some cases where extra messages are needed, or
higher loss in the extra-message case (compound no-SR/RR), or use a
proxy/gateway that demuxes incoming compound RTCPs before putting them on
the radio link.

My personal goal: I'd have loved to be able to simply say "compound is no
longer required, and RR/SR only need to be sent every 5 seconds on average"
(roughly).

If there's consensus that pure single RTCP is the real need here and the
feedback frequency/bandwidth isn't important (enough), I'm ok with that.

---

From: David R Oran <[email-masked]>
Date: Wed, 9 Apr 2008 17:43:32 -0400

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:
>>> Therefore I
>>> compound
> answerer

---

From: Randell Jesup <[email-masked]>
Date: Wed, 09 Apr 2008 18:49:23 -0400

David R Oran <[email-masked]> writes:
>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?

That was one of the feedback cases I was considering, and there might be
a TMMBR message or the like, etc.

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 10 Apr 2008 07:19:39 +0200

Hi

I believe I have to blame myself for not being clear enough. 
What I meant was that in the next update of the draft I will go for a
solution without the proposed single vs multiple negotiation. 

I will propose to make it possible to transmit multiple feedback
messages in a lower layer datagram and still call these packets
non-compound. 
The defintion of non-compound is then according to the lates "pre -04"
version that I have on my desk:

   A non-compound RTCP is a packet that deviates from the rules
   regarding (minimal) compound RTCP given in RFC3550/4585 in the aspect
   that they don't contain both the mandatory elements SR/RR and SDES-
   CNAME.  The definition does not make any distintion based of size,
   which means that it is possible to transmit multiple feedback
   messages in one lower layer datagram.

I have also added a clause:

   The result of this definition may be that the resulting size of non-
   compound RTCP can become larger than a normal compound RTCP.  For
   applications that use access types that are sensitive to packet size
   (see Section 3.1) it is RECOMMENDED to transmit single feedback
   messages in each lower layer datagram.

I have some additional editing to do before I upload the new version.

Regards
/Ingemar

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: den 9 april 2008 17:41
To: Ingemar Johansson S
Cc: Colin Perkins; David R Oran; IETF AVT WG
Subject: Re: [AVT] Non-compound RTCP

"Ingemar Johansson S" <[email-masked]> writes:
>I am currently rewriting the draft and from the discussion sofar I get 
>a feeling that there is a rough 2(or 3) against 1 vote in favor of 
>making things as simple as possible. In other words, no single vs 
>multiple negotiation and I will likely go for the simple solution in 
>the next update of the draft.

>trycky to manage, it essentially goes against all the initial 
>motivation for the non-compound draft and as such is diffucult to cram 
>into the draft without making the whole thing look silly. Hopefully the

>next update of the draft will manage to avoid this.

I realize that the main motivation for a draft was the radio packet size
issues, but a secondary motivation (for people like me) is to reduce
RTCP bandwidth use, especially when using a lot of AVPF feedback and
codec control messages.  (A useful side-effect is lower average feedback
sizes means more feedback is possible without having to hold it off.) In
those cases it's possible that a strict 1-message-per-UDP-packet rule
could lose some of the advantage gained by dropping RR/SR.

There are similar but not fully compatible goals here.  We need to
either make something that deals with both goals (like the
single/multiple stuff) with some added complexity (and maybe that's ok,
especially if it's easy to test), or make a single solution that isn't
optimal for one side.  Either extra bandwidth use in some cases where
extra messages are needed, or higher loss in the extra-message case
(compound no-SR/RR), or use a proxy/gateway that demuxes incoming
compound RTCPs before putting them on the radio link.

My personal goal: I'd have loved to be able to simply say "compound is
no longer required, and RR/SR only need to be sent every 5 seconds on
average"
(roughly).