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

From: Michael A Dolan <[email-masked]>
Date: Thu, 19 Jul 2007 16:47:37 -0700

Hi Hari-

Thank you for your thoughts.

In my survey of extensions (which was certainly not exhaustive) in 
all cases, the 4 bit fields save nothing due to field alignment being 
more important than bit savings.  Of course, potential extensions 
such as byte strings would save one byte per sub-extension in the 
current design.  But all field-aligned 16-byte and 32-byte extension 
fields save nothing.  If this is the basis of the objection, then I 
think we'd need to survey the extensions in use and anticipated and 
form a more technical comparison of the bit savings of 4 versus 8, 
which I maintain is negligible.

My thinking in the proposal below was that it would be better to 
capture the recommended and alternate ID/LEN sizes in one 
document.  I can of course create a 2nd Informational RFC (discussed 
as an option earlier in this thread), but before I did that I would 
poke at the 4-bit design further.  The "defined by profile" field 
value is, of course, arbitrary.

The need comes from the design below being deployed in commercial 
products.  We *do* agree that it is desirable to have only one 
recommended design. So, the question is how best to achieve 
that?  How important is it to preserve a 4-bit design (why, exactly?) 
and the (arbitrary) value 0xBEDE?

Regards,

         Mike

At 04:08 PM 7/19/2007, Desineni, Harikishan wrote:
> >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.
>
>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

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

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

---

From: Michael A Dolan <[email-masked]>
Date: Thu, 19 Jul 2007 16:52:17 -0700

Sorry. "...16-bit and 32-bit..." below.

At 04:47 PM 7/19/2007, Michael A Dolan wrote:
>all cases, the 4 bit fields save nothing due to field alignment 
>being more important than bit savings.  Of course, potential 
>extensions such as byte strings would save one byte per 
>sub-extension in the current design.  But all field-aligned 16-byte 
>and 32-byte extension fields save nothing.  If this is the basis of 
>the objection, then I think we'd need to survey the extensions in 
>use and anticipated and form a more technical comparison of the bit 
>savings of 4 versus 8, which I maintain is negligible.
>
>that?  How important is it to preserve a 4-bit design (why, 
>exactly?) and the (arbitrary) value 0xBEDE?
>
>Regards,
>
>         Mike
>

---

From: Dave Singer <[email-masked]>
Date: Wed, 25 Jul 2007 12:01:35 -0700

At 16:47  -0700 19/07/07, Michael A Dolan wrote:
>capture the recommended and alternate ID/LEN sizes in one document. 
>I can of course create a 2nd Informational RFC (discussed as an 
>option earlier in this thread), but before I did that I would poke 
>at the 4-bit design further.  The "defined by profile" field value 
>is, of course, arbitrary.
>
>recommended design. So, the question is how best to achieve that? 
>How important is it to preserve a 4-bit design (why, exactly?) and 
>the (arbitrary) value 0xBEDE?

OK

The transmission offset is carefully 24 bits, so it fits into a long 
with its 4+4 header.

Similarly the compact form of the SMPTE time-code is 24 bits.

So, the only two I have defined do, in fact, fit.  If I went to an 
8+8 I'd have to fit these into 16 bits (which is clearly too small 
for SMPTE TC), or use padding.

I used the 4+4 design because of a general sense that header 
extensions shouldn't 'swamp' the packet, and to be compact;  just 
general caution, no more.

BEDE was clearly an arbitrary number.  I have no problems changing it.

Choices:

a) go with just 4+4 or just 8+8, and drop one.  I am aware of 
implementations of both, so this isn't ideal.

b) in the same document, require support for both.

c) in the same document, require support for one, and recommend 
support for the other.

d) publish one separately, as an informational RFC.

Personally, I prefer (b) or (c), with a slight preference for (c).

-- 
David Singer
Apple/QuickTime

---

From: Michael A Dolan <[email-masked]>
Date: Wed, 25 Jul 2007 17:06:51 -0700

Dave and all-

I was hoping to avoid a debate on relative deployment and the value 
of 4 bits versus 8 bits by proposing option (c) below (which is what 
I tried to articulate in last week's post).  In a perfect world, we 
would drive to (a), but I don't see how to get there in any 
reasonable timeline.  Mean-time the world moves on making more of 
these deployments, and worse, more non-conformant variants we don't 
even know about....

Can everyone live with option (c)?

Regards,

         Mike

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Jul 2007 21:03:54 +0200

Michael A Dolan skrev:
> Dave and all-
> 
> I was hoping to avoid a debate on relative deployment and the value of 4 
> bits versus 8 bits by proposing option (c) below (which is what I tried 
> to articulate in last week's post).  In a perfect world, we would drive 
> to (a), but I don't see how to get there in any reasonable timeline.  
> Mean-time the world moves on making more of these deployments, and 
> worse, more non-conformant variants we don't even know about....
> 

Preferably no, this is a core extension that we are likely to see quite 
a lot of use in the future. I think 4+4 has a good tradeoff. I would 
like to go with a) because of this to avoid confusing things. If there 
are "proprieatery" deployment as it is of 8+8 that is not different from 
other "proprieatery" extensions in this field.

>> d) publish one separately, as an informational RFC.

Cheers

Magnus Westerlund

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

---

From: Michael A Dolan <[email-masked]>
Date: Sun, 29 Jul 2007 19:02:03 -0700

Magnus-

We all agree the preferable choice is option (a), but how do we get 
there?  The management of the RTP header extensions is not ideal due 
to circumstances now behind us.  I don't see how we can make existing 
conformant practice (nearly anything) non-conformant upon publication 
of this ID.  At best, all a STDs track publication can say is 
"SHOULD" at this point in my personal view.  It is not likely to be 
as simple as managing the "defined by profile" field as an enumerated 
field by IANA or explicit RFC publication as some have suggested, 
since 3350 gave no indication at all how to manage this field or even 
if it was a constant (which some presume incorrectly).

IETF AVT WG is an open process. All other existing current extension 
syntax authors are invited to try and make the effort to merge them 
into a single compatible standard design as part of the 
process.  Although I wish I was aware of this other design sooner in 
the process, I tried to craft the proposal in this thread so that 
both could exist concurrently in a well-structured manner.  I would 
welcome other uses to come forward so we could craft a single overall 
mechanism.  We all *know* there are other uses (I found a new one 
last week), but the burden is on those authors to come forward and 
make the effort. Lacking other contributions, the WG should make an 
effort to make the published ones (minimally these two) work as best we can.

I am still trying to avoid an evaluation ("bake-off") of the two 
designs since it will alienate one of them after the fact, but....you 
cite "tradeoff" and "proprietary" evaluation criteria to support the 
4/4-bit design alone in pursuit of option (a).  So if the path 
forward is to have a technical evaluation of tradeoffs and relative 
"propriety" to reach option (a), then I would like to understand your 
conclusions better, especially the one about one being more 
proprietary than another.

But before we enter into a "bake-off", it is still my view that the 
best we can accomplish under the circumstances of how 3350 left 
things is to document what practices we know about (via authors 
willing to bring them forward) in a clearly discriminating manner, 
concurrent with a recommendation for all new designs.  Please note 
that I did not try to assert that the other design in this thread as 
the preferred one - the contrary in fact, deferring to the existing 
ID's proposal for future designs.

Regards,

         Mike

At 12:03 PM 7/26/2007, Magnus Westerlund wrote:
>>of 4 bits versus 8 bits by proposing option (c) below (which is 
>>what I tried to articulate in last week's post).  In a perfect 
>>world, we would drive to (a), but I don't see how to get there in 
>>any reasonable timeline.
>Preferably no, this is a core extension that we are likely to see 
>quite a lot of use in the future. I think 4+4 has a good tradeoff. I 
>would like to go with a) because of this to avoid confusing things. 
>If there are "proprieatery" deployment as it is of 8+8 that is not 
>different from other "proprieatery" extensions in this field.
>
>>>Choices:
>>>

---

From: Dave Singer <[email-masked]>
Date: Mon, 30 Jul 2007 10:13:21 -0700

At 19:02  -0700 29/07/07, Michael A Dolan wrote:
>to circumstances now behind us.  I don't see how we can make 
>existing conformant practice (nearly anything) non-conformant upon 
>publication of this ID.

I want to be very clear;  neither my draft, nor any of the options 
outlined below, would make any previously conformant practice 
non-conformant.  No matter what we do with this draft, existing legal 
practices should stay legal, in my opinion.  We are only debating the 
degree and location of their documentation.

So, really (a) and (d) are a pair;  if we go (a), Mike is always free 
to do an informational RFC.

Which is why I think I would like to document them in one document, 
with 4+4 support required and 8+8 documented and mentioned and 
support for it optional.

p.s. I thought we had solved all remaining issues, includiing IANA, 
until this came up.  I really want to close this out.  My fear is 
that the 8+8 variant is enough of a technical change to the document 
that I'd have to go back through WG last call, IESG review, and all 
that.  I'm not sure I have the energy.

If that is a problem, how about we add a sentence to the 4+4 spec. 
saying "A variant of this design, using 8-bit length and tag fields, 
also exists, using a different value for the field that takes the 
value 0xBEDE here."?

>At best, all a STDs track publication can say is "SHOULD" at this 
>point in my personal view.  It is not likely to be as simple as 
>managing the "defined by profile" field as an enumerated field by 
>IANA or explicit RFC publication as some have suggested, since 3350 
>gave no indication at all how to manage this field or even if it was 
>a constant (which some presume incorrectly).
>
>into a single compatible standard design as part of the process. 
>Although I wish I was aware of this other design sooner in the 
>process, I tried to craft the proposal in this thread so that both 
>could exist concurrently in a well-structured manner.  I would 
>welcome other uses to come forward so we could craft a single 
>overall mechanism.  We all *know* there are other uses (I found a 
>new one last week), but the burden is on those authors to come 
>forward and make the effort. Lacking other contributions, the WG 
>should make an effort to make the published ones (minimally these 
>two) work as best we can.
>
>designs since it will alienate one of them after the fact, 
>but....you cite "tradeoff" and "proprietary" evaluation criteria to 
>support the 4/4-bit design alone in pursuit of option (a).  So if 
>the path forward is to have a technical evaluation of tradeoffs and 
>relative "propriety" to reach option (a), then I would like to 
>understand your conclusions better, especially the one about one 
>being more proprietary than another.
>
>>>I was hoping to avoid a debate on relative deployment and the 
>>>value of 4 bits versus 8 bits by proposing option (c) below (which 
>>>is what I tried to articulate in last week's post).  In a perfect 
>>quite a lot of use in the future. I think 4+4 has a good tradeoff. 
>>I would like to go with a) because of this to avoid confusing 
>>things. If there are "proprieatery" deployment as it is of 8+8 that 
>>is not different from other "proprieatery" extensions in this field.
>>
>>>>Choices:
>>>>

-- 
David Singer
Apple/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jul 2007 14:24:42 +0200

Hi,

IETF standards track documents are strong recommendations on how to 
solve a problem. In many case that doesn't rule out the existence of 
other solutions. However, it may hurt interoperability and/or complicate 
  implementations. There is no protocol police that goes ut and stop 
usage that doesn't follow IETF. In addition the header extension 
mechanism in RTP is free to use by anyone. So 8+8 is definitely 
conformant to RFC 3550. One has only to be aware of the limitations they 
result in. But the desirable future is that anyone in the future that 
needs this functionality will use RFC XXX (what ever the number will be 
for draft-ietf-avt-hdrext).

As I see it the best we can do for the future is to select one solution 
and go forward. And hope that most future users out there uses that 
single solution. That is in my view the best way and will maximize 
interoperability in the future. I can also hope that some that uses 
their own extension mechanism will move to the IETF defined one.

 > with 4+4 support required and 8+8 documented and mentioned and

I hope that it is clearer why I propose to select only a single one and 
stick with that. I don't want to have two of them in the document 
because that will result in that everyone will have to implement both. 
IETF has become worse and worse at selecting a single solution and 
sticking with it. I asked the question about deployement, because as I 
see it there are some difference in the technical tradeoff but if you 
had a large deployement that would still be compatible with the tag 
value mechanism in the current WG document then I think it would have 
been reasonable to switch to the 8+8 tradeoff. However, as you aren't 
forthcomming with that information there is no data to for determinging 
that 8+8 would be a more reasonable choice then 4+4. I am also worried 
about the ID numberspace and control over that.

I am worried about the 8+8 ID namespace that may make it difficult to 
adopt. draft-ietf-avt-hdrext contains a larger namespace that is mapped 
onto the ID values. This as 16 values would never last. But the same is 
also true for 256 values. Thus the same rule could be applied. However, 
that requires that IETF gets full control of at least a substantial 
block of the field values. There must be full agreement between the 
original definers and IETF that control is transfered. In addition it 
must be known which values are used and already handed out. The only 
alternative for a 8+8 solutio would be to go with another header 
extension identifier.

Because of that I would propose that we go forward with a document that 
only provides the 4+4 solution.

Dave Singer skrev:
> also exists, using a different value for the field that takes the value 
> 0xBEDE here."?
> 

There might be value in pointing out that there exist similar but not 
IETF defined solutions for the header extension field. However, I wonder 
if it would confuse more then any benefit it gives. But my attempt is 
the following:

"At least one similar solution is known to exist for solving the first 
drawback.  That solution uses different field lengths, but also another 
16-bit identifier value, thus no risk of misstake between them exist. 
The resolution of the second drawback and slightly differnt tradebacks 
resulted in the solution present in this document."

The above is written based on that the solution you documents did not 
try to resolve the namespace issues to provide an basically unlimited 
number of header extensions.

I might have not given the impression before that there is benefit in 
document the 8+8 solutions that are in use. I think it would be best 
that it is documented in an informational RFC. However, I would like to 
see good wording in there that this is a documentation of something that 
is used, but that it is prefered to use draft-ietf-avt-hdrext.

Cheers

Magnus Westerlund