Subject: Re: [AVT] General extensible RTP header extension mechanism

From: lazzaro <[email-masked]>
Date: Sun, 2 Apr 2006 12:26:40 -0700

On Apr 2, 2006, at 9:00 AM, Cullen Jennings wrote:
> Given the very few number of header extensions proposed, I don't  
> know how
> many people need this. Can people who have a application that would  
> make use
> of this and that would implement it let the chairs know that they  
> need this?

If we only design for the applications envisioned by folks who
are subscribed to the list today, we won't have a protocol ready
for use for new applications areas that come into being 3-5 years
from now.  By and large the folks who pioneer those applications will
be experts in fields other than networking; today, they probably  
don't even
know what RTP is, so they aren't on this list and can't speak for  
themselves.

There will be a narrow window of time where they evaluate using RTP
vs. designing a new protocol for their new industry on top of UDP (like,
for example, networked computer games have done, by and large).

I think the header extension work is a safety valve that is
needed to let these yet-to-be-envisioned applications to use
RTP instead of inventing a new protocol.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

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

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 3 Apr 2006 10:04:10 +0200

Hi Cullen,

I agree with John.  Other arguments for this work are:

- non-IETF organizations have already started utilizing this bit (and  
the header extension concept) on the grounds that it's around for the  
better part of a decade, and the IETF did not bother using it.  This  
breaks interoperability among application spaces.  While this may not  
be a concern for the immediate future, it could cause problems in the  
long term.
- We did not use the extension mechanism, primarily because we hadn't  
an extensible mechanism available.  Dave's draft is changing this.   
Once extensions are available, people will start using them.

As a prime example for the use of the extension mechanism I would  
cite the transmission of additional timestamps (e.g. decoding TS) --  
which has been identified many times as a major shortcoming of the  
original RTP design.  in addition, I could envision the control data  
for generic packet interleaving schemes.  Many modern payload formats  
identified the need for interleaving, and a more generic solution, I  
believe, would be desirable to reduce the specification size of  
future payload formats.

Regards,
Stephan

On  2 Apr2006, at 21:26 , lazzaro wrote:

>> many people need this. Can people who have a application that  
>> would make use

---

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Apr 2006 19:16:19 +0100

On 3 Apr 2006, at 09:04, Stephan Wenger wrote:
> - non-IETF organizations have already started utilizing this bit  
> (and the header extension concept) on the grounds that it's around  
> for the better part of a decade, and the IETF did not bother using  
> it.  This breaks interoperability among application spaces.  While  
> this may not be a concern for the immediate future, it could cause  
> problems in the long term.
> - We did not use the extension mechanism, primarily because we  
> hadn't an extensible mechanism available.  Dave's draft is changing  
> this.  Once extensions are available, people will start using them.
>
> cite the transmission of additional timestamps (e.g. decoding TS)  
> -- which has been identified many times as a major shortcoming of  
> the original RTP design.  in addition, I could envision the control  
> data for generic packet interleaving schemes.  Many modern payload  
> formats identified the need for interleaving, and a more generic  
> solution, I believe, would be desirable to reduce the specification  
> size of future payload formats.

Perhaps, but it's not clear that a header extension is the right  
place for a generic interleaving scheme (vs. putting it into a  
container payload format, as was done with the various FEC proposals).

Colin

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 05 Apr 2006 09:57:40 -0700

I completely get the need for an extension mechanism that is easy to use and
easy for people to add their extension. What I don't understand is why this
approach vs. others - for example an IANA registry approach. I'm totally
willing to be convinced their is a good reason - I just don't get it yet so
someone enlighten me.

---

From: lazzaro <[email-masked]>
Date: Wed, 5 Apr 2006 11:30:04 -0700

> willing to be convinced their is a good reason - I just don't get  

I think it is best for David Singer to officially reply to your request,
since it is his design ...

However, my personal view is that the experience of Java community
with the reverse-domain-name mechanism for creating unique
name spaces has been a good one.  It provides "uniqueness"
without the hassle factor of requiring registration with a body
like IANA.  I think current media-type experience shows that a lot
of "rogue" media types enter into common usage without
IANA registration (example: MIDI files), because of a lack of
knowledge of how IANA works, or because of a philosophical
or competitive aversion to registration. The reverse-domain-name
mechanism is a way to solve the uniqueness problem without a
formal registration system.

---
John Lazzaro

---

From: Dave Singer <[email-masked]>
Date: Thu, 6 Apr 2006 09:13:06 +0100

>formal registration system.

Yes exactly.  My sense was that this was an arena in which we wanted 
to make sure people "did the right thing" without necessarily 
requiring the weight of a formal registration process.  My sense is 
that for items like this ("small things") we tend to see many people 
using and then registering much later.  I mean, look at the number of 
X- mime types, which is much more serious.

Let me turn this over.  What is the *advantage* of the fully 
registered approach?
-- 
David Singer
Apple Computer/QuickTime