[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ULE Extension Headers
Gorry:
Thanks for sharing your assessment about (c). Given that assessment is on
the record, I now see the basis for your judging that we are not quite there
yet.
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 4:43 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: ULE Extension Headers
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.
>