RE: ULE Extension Headers

[William StanisLaus <williams77@mailandnews.com>]

Hi,
I'll Volunteer for ULE extension header definition and encoding/decoding at 
sender/receiver. Also few examples.
~William.

-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk] On 
Behalf Of Gorry Fairhurst
Sent: Thursday, March 11, 2004 9:58 PM
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.