Subject: Re: [AVT] draft-ietf-avt-hdrext-12

From: Colin Perkins <[email-masked]>
Date: Fri, 6 Jul 2007 11:39:04 +0100

Mike,

On 25 Jun 2007, at 16:32, Michael A Dolan wrote:
> In review of the actual sub-extensions in use, they could  
> theoretically have been implemented with the design in the ID.  
> There is evidence that their work pre-dated hdrext-00, so it  
> appears purely a historical accident.
>
> FYI, I have been retained by the implementers to publicly document  
> their work, and am beginning that process.  So, this is not  
> research project or informational report.

Without knowing the community of support for this mechanism, would it  
make sense to document it as an Informational RFC, with the  
recommendation that implementations move to using Dave's draft over  
time (i.e. in much the way draft-hunt-avt-rtcpxnq-00.txt documents  
BT's RTCP XR extensions)?

> I don't have any data on how widely deployed the system is - I  
> could inquire. Although I understand the rationale for the  
> question, I hesitate to enter into a debate over relative  
> "deployedness".  Regardless of the measure used (# units, #sites,  
> #independent implementations), I need to document what they did (at  
> least in a compatible way).  I have therefore personally leapt to  
> the state of mind of both designs being fait à compli, so my intent  
> was to capture the two variants in one place as the next best thing  
> to a single design.  FYI, it is possible to discriminate the two  
> easily and unambiguously without altering Dave's design.
>
> Would it be helpful to see the details?

Probably.

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

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

---

From: Michael A Dolan <[email-masked]>
Date: Fri, 06 Jul 2007 08:38:49 -0700

Colin-

A 2nd Informational RFC was my "plan B".  But 
before we abandon the idea of a single document, 
let me explain more details and how the two could 
be merged.  I'll do this in a brief email (rather 
than an ID) under separate cover.

Regards,

         Mike

---

From: Michael A Dolan <[email-masked]>
Date: Thu, 19 Jul 2007 14:33:02 -0700

>>Would it be helpful to see the details?

Colin, Dave and all-

Here's a way to merge the two along with the syntax for the alternate
sub-extension:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ver  |  application-defined  |           length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The ver field indicates the version of the syntax that follows for
the sub-headers. Values 1 and 0xB are defined here.  The other values
are reserved by IETF.

The application-defined field is 12 bits that are application-dependent
and may be defined to be any value or meaning and are outside the scope of
this specification.

For the current ID (ver=0xB), they are set to 0xEDE.  For the alternate
encoding (ver=1), they are set to 0x100x, where x is application-defined.

For ver=1, the bytes following the length field consist of a series of
ID/LEN/VAL (like the current ID) except that the first two fields are
each 8 bits (not 4 bits) as follows:

  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       ID      |     length    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FYI, in the actual sub-extensions that are defined, field alignment
requirements completely outweigh any savings from using 4 bit fields.
That is, the same number of bytes are used to encode the extensions
using either 4- or 8-bit ID/LEN fields since the extension fields
need to be field-size aligned and thus padding out to 16 or 32 bits
is nearly always required in both designs.  I.e. 4-bit ID/LEN fields
just doesn't save anything in current practice.  That's not to say
they couldn't be more efficient in some application - just not one
I've seen.

Comments?

Regards,

         Mike

-----------------------------------
Michael DOLAN
Television Broadcast Technology, Inc. (TBT)
PO Box 190, Del Mar, CA 92014 USA
+1-858-755-6661    FAX: +1-858-755-6669
URL:http://www.newtbt.com

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 19 Jul 2007 16:08:12 -0700

>is nearly always required in both designs.

May not be correct, might have to disagree here. It depends on the
number and size of extensions. 

Note that the scope of 0xBEDE profile extension is RTP/AVP profile and
all its extensions. I see your proposal as a new (0x100x) header
extension format for the same RTP profiles (RTP/AVP and extensions). 

I think the question that needs to be answered is "Is there is a need
for standardizing multiple header extensions for a given (or set of) RTP
profile(s)?"

I am comfortable to see just one header extension format per RTP
profile. I prefer to keep 0xBEDE as the RECOMMENDED header extension
format for RTP/AVP profile and its extensions. 

At this time, I think that taking the informational RFC route for 0x100x
would be a better approach.

--Hari