Re: ULE Extension Headers

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

On 11/3/04 6:02 pm, "Allison, Art" <AAllison@nab.org> wrote:

> With respect, I have seen no one register any other preference than (b) on
> list. 
> I have been doing standards work for over 20 years and one always
> wants to get all folks to express their position, but if they will not then
> those who do represent the consensus and you move on.

I don't believe we have reached this stage of HAVING to decide, I want to
get this correct. 

I **DO** still welcome inputs from any others on the list.

> 
> I don't see lack of a consensus in this matter, by any standard for
> consensus.  Perhaps there is off-list correspondence, but with respect that
> is not appropriate to consider here.
> 
> Gorry, if you do not support (b), and are feel your posting is inhibited
> because you are the Chair, perhaps just post with your "Chair hat off" for
> the record.

OK, my thoughts are: I can see pros and cons in (b) and (c ) - at the moment
looking at our implementation approach it looks like c will probably be
easier to implement and offers easy parsing of multiple extensions....


> 
> Art
> ::{)>
> Art Allison
> Director Advanced Engineering
> NAB
> 1771 N St NW
> Washington DC 20036
> 202 429 5418
> 
> 
> -----Original Message-----
> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> Sent: Thursday, March 11, 2004 11:28 AM
> To: ip-dvb@erg.abdn.ac.uk
> Subject: Re: ULE Extension Headers
> 
> 
> 
> Let's see if I can help steer this discussion.
> 
> * I note there is some enthusiasm to consider the idea of a ULE extension
> header. That is useful to know, but I don't see a consensus YET.
> 
> * As I said earlier, I am against holding-up the publishing of the first rev
> of the ULE WG draft.  I believe we should publish the draft as soon as
> possible (next week), to make sure the rest of the text is acceptable to the
> WG. We CAN issue a new revision of the ID soon after with this new
> functionality (if we are ready) - there's no minimum time between
> revisions!!!
> 
> Here is my suggestion to progress the extension header topic:
> 
> * We need first to at least find a list of examples of likely/potential
> use...  Let us do this in the context of setting some (potential/actual)
> requirements/architecture - this also is a WG charter item!  Any volunteers
> of 1-3 paragraphs of ID text describing for each of the ideas for use:
> Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else?
> 
> * I'm not yet clear of the relative costs of (a,b,c) in terms of
> implementation, registry management, transmission efficiency - one thing
> that would be very useful would be to write a short ID with a proposed
> solution, to have something concrete to compare the design options with.
> 
> Any volunteers for either of the above?
> 
> Gorry
> 
> P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the
> options I had seen... Sorry if that caused some confusion.
> 
> On 10/3/04 5:32 pm, "Alain RITOUX" <alain.ritoux@6wind.com> wrote:
> 
>> 
>> 
>> Allison, Art wrote:
>>> Taking one....
>>> (1) ULE Extension Headers - We have described a number of ways we can
>>> encode extra headers associated with a specific SNDU, that a receiver
>>> may optionally ignore without having to discard a PDU. However, we
>>> have yet to agree if this is needed and which way is best. The most
>>> promising seem to be:
>>>     (a) use a 16-bit type field to indicate "extension header follows"
>>>     (b) use a 1-bit flag to indicate "extension header follows"
>>>     (c) the assignment of type field values to identify each
>>>         individual extension header.
>>> 
>>> I recommend we add only a "place holder note" in the next revision of
>>> the ULE draft (to be released in about one-two weeks) which says the WG
>>> could possibly consider future extension headers (if needed), and
>>> continue this discussion for the next revision (this can happen quickly
>>> if the WG gets consensus, at the moment I see too many options
>>> and unclear concrete examples).
>>> 
>>> ----
>>> I thought discussion faded to silence after I <effectively> acknowledged
> (b)
>>> was ok with me. (And I thought some wanted to define the following
> structure
>>> when the bit is set - an activity to which I do not think there were
>>> objections.)
>> 
>> I also am in favour of b) A structure was proposed for the case where
>> the bit is set. I didn't feel any strong objection against the proposed
>> definition, neither a great support ;-) but we were just 3 or 4 to
>> discuss about it, I don't know the feeling of the WG about this stuff.
>> How to proceed any further ?
>> 
>>> So maybe we have acceptance of an approach for this item?
>> maybe.
>> 
>> Cheers.
>> Alain.
>