Subject: Re: [AVT] I-D Action:draft-ott-avt-rtcp-guidelines-01.txt

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Jul 2008 08:29:55 +0100

Hi,

On 16 Jun 2008, at 10:18, Ingemar Johansson S wrote:
> First of all I support that this becomes a working group draft
>
> A few comments to the draft :
>
> The guidelines section is a tricky area as much use for RTCP is
> specified in many different foras. Examples are OMA PoC where RTCP APP
> is used. Another use is the speech codec adapation defined in 3GPP
> TS26.114 which also use RTCP APP. Besides this there may be more
> application specific (or standards-forum) specific exotic use of RTCP
> emerging.
> While I am in some sense in favor of such extensions (also found  
> guilty
> of helping to introduce one) I understand fully the worries  
> expressed in
> the draft that this is a potential problem e.g in terms of
> interoperability between systems which may in the end introduce more
> complexity in gateways.
> IETF cannot probably prevent this from happening but I believe that  
> the
> draft may cause implementors to stop and think a bit more (and wider)
> before implementing extensions.

That's at least partly the hope. Also, we want to discourage use of  
RTCP APP for standard extensions, in favour of the other RTCP  
extension mechanisms if possible (e.g. new RTCP packet types).

> Multicast is one factor to consider throughout the design but  
> personally
> I don't even bother with multicast and I have a feeling that it may  
> be a
> feeling shared by others active in other standards fora. Why should we
> bother with multicast in the design if we know for sure that this
> particular extension is not intended for multicast use?. I am not  
> saying
> that we should forget about multicast but I believe that some  
> amount of
> relaxation that allows the implementor to "unthink" multicast or huge
> groups may be useful (together with a requirement to recognize the
> limitation). I believe that many implementors think this way  
> already so
> I probably kick in an open door.

Because you don't know for sure that the extension is not intended  
for use with groups (either IP multicast groups, or application-layer  
groups using RTP mixers or RTP-aware MCUs). RTP is a group  
communication protocol - get used to it :-)

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

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 4 Jul 2008 14:49:29 +0200

Hi
 
Comments below
 
/Ingemar

________________________________

	From: Colin Perkins [mailto:[email-masked]] 
	Sent: den 4 juli 2008 09:30
	To: Ingemar Johansson S
	Cc: [email-masked]; [email-masked]
	Subject: Re: [AVT] I-D
Action:draft-ott-avt-rtcp-guidelines-01.txt

	Hi, 

		First of all I support that this becomes a working group
draft

		The guidelines section is a tricky area as much use for
RTCP is
		specified in many different foras. Examples are OMA PoC
where RTCP APP
		is used. Another use is the speech codec adapation
defined in 3GPP
		TS26.114 which also use RTCP APP. Besides this there may
be more
		application specific (or standards-forum) specific
exotic use of RTCP
		emerging. 
		While I am in some sense in favor of such extensions
(also found guilty
		of helping to introduce one) I understand fully the
worries expressed in
		the draft that this is a potential problem e.g in terms
of
		interoperability between systems which may in the end
introduce more
		complexity in gateways. 
		IETF cannot probably prevent this from happening but I
believe that the
		draft may cause implementors to stop and think a bit
more (and wider)
		before implementing extensions. 

	That's at least partly the hope. Also, we want to discourage use
of RTCP APP for standard extensions, in favour of the other RTCP
extension mechanisms if possible (e.g. new RTCP packet types). 

I believe  one of the problems with IETF RTCP extensions is that they
generally take some time to push through and very often other standards
bodies wanted the thing already yesterday. Thats why RTCP_APP has been
specified for e.g OMA Poc, 3GPP PSS and 3GPP MTSI. 
My take is that future use of RTCP_APP in other standards bodies is
inevitable. It is fast and it does the job within the given limitations.

I would say that an IETF standpoint like "pleeeeease don't use RTCP_APP
but if you do then take these considerations into account..." rest is
T.B.D.... This text would be a recommendation towards people active in
other standards bodies. In IETF specs I belive that RTCP_APP should not
be allowed..

		Multicast is one factor to consider throughout the
design but personally
		I don't even bother with multicast and I have a feeling
that it may be a
		feeling shared by others active in other standards fora.
Why should we
		bother with multicast in the design if we know for sure
that this
		particular extension is not intended for multicast use?.
I am not saying
		that we should forget about multicast but I believe that
some amount of
		relaxation that allows the implementor to "unthink"
multicast or huge
		groups may be useful (together with a requirement to
recognize the
		limitation). I believe that many implementors think this
way already so
		I probably kick in an open door.

	Because you don't know for sure that the extension is not
intended for use with groups (either IP multicast groups, or
application-layer groups using RTP mixers or RTP-aware MCUs). RTP is a
group communication protocol - get used to it :-) 

Trying hard to get used to it, in a few years maybe :-). Still I believe
that in some cases RTP would benefit if one could consider
"non-multicast" in designs. 

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Jul 2008 14:38:45 +0100

Hi,

On 4 Jul 2008, at 13:49, Ingemar Johansson S wrote:
> I believe  one of the problems with IETF RTCP extensions is that  
> they generally take some time to push through and very often other  
> standards bodies wanted the thing already yesterday. Thats why  
> RTCP_APP has been specified for e.g OMA Poc, 3GPP PSS and 3GPP MTSI.

Other standards bodies can register new RTCP packet types almost as  
easily as they can define new RTCP APP packets. See RFC 3550 section  
15 - the policy is specification required, not RFC required.

> I would say that an IETF standpoint like "pleeeeease don't use  
> RTCP_APP  but if you do then take these considerations into  
> account..." rest is T.B.D.... This text would be a recommendation  
> towards people active in other standards bodies. In IETF specs I  
> belive that RTCP_APP should not be allowed..

No, the intention is to say "don't use RTCP APP in standards  
documents, use these other, more appropriate, mechanisms instead". If  
that's not clear, we need to update the text in the rtcp-guidelines  
draft.

Colin

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Sat, 5 Jul 2008 12:44:36 +0200

Hi

	From: Colin Perkins [mailto:[email-masked]] 
	Sent: den 4 juli 2008 15:39
	To: Ingemar Johansson S
	Cc: [email-masked]; [email-masked]
	Subject: Re: [AVT] I-D
Action:draft-ott-avt-rtcp-guidelines-01.txt

	Hi, 

			That's at least partly the hope. Also, we want
to discourage use of RTCP APP for standard extensions, in favour of the
other RTCP extension mechanisms if possible (e.g. new RTCP packet
types). 

		I believe  one of the problems with IETF RTCP extensions
is that they generally take some time to push through and very often
other standards bodies wanted the thing already yesterday. Thats why
RTCP_APP has been specified for e.g OMA Poc, 3GPP PSS and 3GPP MTSI.

	Other standards bodies can register new RTCP packet types almost
as easily as they can define new RTCP APP packets. See RFC 3550 section
15 - the policy is specification required, not RFC required. 

As the number space of RTCP packet types is rather limited I can imagine
that there will be some resistance from the IANA here. Today I see a few
3GPP contributions that wish to use (and use) RTCP_APP in different ways
and with my "non-IETF" hat on I can see a  bunch of benefits, the
subtype and name fields on the RTCP_APP allows for some "number-space"
and the use is not experimental something that is in direct conflict
with the guidelines.
 
I believe that the guidlines are well written, the problem is maybe that
either they need to be communicated better (and here I too have a
responsibility..) . Another issue is that I can sense a resistance
against e.g the specification of new AVPF application layer specific
feedback messages as the service in question may be very specialized and
teh number space is limited.
Here it is maybe better for other standards bodies to register e.g a new
RTCP_3GPP (or RTCP_OMA ?) packet type for "specialized use" but in the
guidelines include a disclaimer about e.g the interoperabilty issues
that may arise. 

		My take is that future use of RTCP_APP in other
standards bodies is inevitable. It is fast and it does the job within
the given limitations. 
		I would say that an IETF standpoint like "pleeeeease
don't use RTCP_APP  but if you do then take these considerations into
account..." rest is T.B.D.... This text would be a recommendation
towards people active in other standards bodies. In IETF specs I belive
that RTCP_APP should not be allowed..

I can understand the IETF statement, problem is I believe to convince
other standard bodies to follow the same principle, something  that is
not the case today. 

	Colin

---

From: Colin Perkins <[email-masked]>
Date: Sun, 20 Jul 2008 10:39:39 +0100

Hi,

On 5 Jul 2008, at 11:44, Ingemar Johansson S wrote:
> As the number space of RTCP packet types is rather limited I can  
> imagine that there will be some resistance from the IANA here.

The IANA follows the guidelines we give them, so there will be no  
resistance there. There are currently 10 RTCP packet types  
registered, out of an eight-bit space, so we're not in an immediate  
shortage (especially since extensions often are in a form that can  
share a packet type for several related items, in the way RTCP XR  
does, for example).

> Today I see a few 3GPP contributions that wish to use (and use)  
> RTCP_APP in different ways and with my "non-IETF" hat on I can see  
> a  bunch of benefits, the subtype and name fields on the RTCP_APP  
> allows for some "number-space" and the use is not experimental  
> something that is in direct conflict with the guidelines.

Can you elaborate on what are these contributions, and what are the  
perceived benefits of RTCP APP compared to the other approaches?

> I believe that the guidlines are well written, the problem is maybe  
> that  either they need to be communicated better (and here I too  
> have a responsibility..) . Another issue is that I can sense a  
> resistance against e.g the specification of new AVPF application  
> layer specific feedback messages as the service in question may be  
> very specialized and teh number space is limited.

For some of these, if they're very specialised, it may be good to  
question whether RTCP is an appropriate transport, or if there is  
some other protocol to be used. That's one of the points of this  
draft: to encourage people to consider if RTCP is the right option.

> Here it is maybe better for other standards bodies to register e.g  
> a new RTCP_3GPP (or RTCP_OMA ?) packet type for "specialized use"  
> but in the guidelines include a disclaimer about e.g the  
> interoperabilty issues that may arise.

That ways lies madness and non-interoperability.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Jul 2008 11:21:37 +0200

Colin Perkins skrev:
> resistance there. There are currently 10 RTCP packet types registered, 
> out of an eight-bit space, so we're not in an immediate shortage 
> (especially since extensions often are in a form that can share a packet 
> type for several related items, in the way RTCP XR does, for example).

Agreed, but you and me have in fact only the space 194-223 to be first 
class citizen. If we start assigning outside of that RTP/RTCP MUX will 
be affected.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt