Re: ULE Extension Headers

["Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>]

I volunteer for some examples.

Marie-Jose
----- Original Message ----- 
From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Thursday, March 11, 2004 11:28 AM
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.
>
>