Subject: [AVT] (no subject)

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 11 Mar 2008 23:30:12 +0100

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. 

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.

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. 

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
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Tue, 11 Mar 2008 18:37:45 -0400

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 11 Mar 2008 23:54:07 +0100

Hi

Comments inline below

/Ingemar

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: den 11 mars 2008 18:38
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: Re: [AVT] (no subject)
> 
> 
> > As a follow up from todays discussion just in order to 
> "cast the iron 
> > while it's hot"
> >
> 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.
> 

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.

---

From: Randell Jesup <[email-masked]>
Date: Tue, 11 Mar 2008 23:40:43 -0400

>> > the codec control messages draft... with the disclaimer that single

I prefer 2 also, though I can certainly live with either.

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

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

Right. The idea behind non-compound is to reduce the size of the messages
by not sending items you don't *need* to send.  If you have multiple things
to send, then (maybe) it makes more sense to send one packet with multiple
things than N packets with one thing.  You still don't want to send stuff
that there's no purpose for, and SR/RR/SDES don't need to be sent more
often than in RFC 3550/etc.

-- 
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, 12 Mar 2008 22:40:33 +0100

Hi

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. 

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.  

Comments welcome

Regards
/Ingemar

> From: Randell Jesup [mailto:[email-masked]] 
> Sent: den 11 mars 2008 23:41
> To: Ingemar Johansson S
> Cc: David R Oran; [email-masked]
> Subject: Re: [AVT] Non-compound RTCP
> 
> >> > 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.
> 
> >> to have as many RTCP packets per UDP packet as you can given space 
> >> and timing constraints. I certainly hope you mean the latter.
> >
> Right. The idea behind non-compound is to reduce the size of 
> the messages by not sending items you don't *need* to send.  
> If you have multiple things to send, then (maybe) it makes 
> more sense to send one packet with multiple things than N 
> packets with one thing.  You still don't want to send stuff 
> that there's no purpose for, and SR/RR/SDES don't need to be 
> sent more often than in RFC 3550/etc.
> 
> --
> 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

---

From: Randell Jesup <[email-masked]>
Date: Wed, 12 Mar 2008 19:17:04 -0400

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

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 13 Mar 2008 22:37:55 +0100

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

> Sent: den 12 mars 2008 19:17
> To: Ingemar Johansson S
> 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.
> 
> >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.
> 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.
> 
> --

---

From: Randell Jesup <[email-masked]>
Date: Thu, 13 Mar 2008 18:33:07 -0400

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Mar 2008 15:48:55 +0100

Hi,

I think this discussion gets back to the fundamental definition of the 
solution. As I see it we have two ways to specify something:

A. A non-compound packet, i.e. which per its name only consists of a 
single RTCP packet in the UDP payload.

B. A non-standard RTCP packet, i.e. where the only restriction removed 
is the need for RR/SR + SDES Cname in the RTCP packet. This also allowes 
for A, but also allows for other arbitary combinations of RTCP packet 
types in the payload. (Although I would exclude BYE from the allowed types)

With the currently defined rules in the draft, going down road B 
actually isn't a problem. If you use larger non-standard packets it only 
results in no reduction in the average size. And when working in 
immediate mode you have to be more conservative. I can understand 
applications that have larger amount of feedback or report information 
that want to avoid having to send compound packets for all of them.

So from my perspective going with B is fine. However, we should probably 
rename a few things and give a good name to compound packets with SR/RR 
+ SDES CNAME.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------