Subject: Re: ULE Extension Headers

From: "William StanisLaus" <[email-masked]>
Date: 10 Mar 2004 17:21:08 -0000

Hi Art,
  Please refer the previous post on definition to the proposal (b) which describes the ext. bit.

http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00584.html

Best Regards,
William.

On Wed, 10 Mar 2004 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.)
>So maybe we have acceptance of an approach for this item?
>
>Art
>::{)>
>Art Allison
>Director Advanced Engineering
>NAB
>1771 N St NW
>Washington DC 20036
>202 429 5418
>
>
>-----Original Message-----
> From: Gorry Fairhurst [mailto:[email-masked]]
>Sent: Monday, March 08, 2004 10:51 AM
>To: [email-masked]
>Subject: ULE : Encryption Support, FEC, and Extension headers.
>
>
>
>There's been a lot of discussion on the list about three related topics:
>     (i) The (potential/actual) need for FEC and Encryption
>     (ii) How to implement headers in ULE to support Encryption
>     (iii) Whether ULE should support optional extension headers.
>
>I don't wnat to stop any of this debate, but I would like to try and put
>a marker in the email threads so that those not following the detail
>of the various discussions, have a picture of where the group seems
>to have consensus.
>
>So here's my recommendation as WG Chair:
>
>(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 optionaly 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).
>
>(2) FEC and Encryption, the requirements for these must be clearly
>defined in an Internet Draft (reference could be made to other, e.g.
>ETSI documents). This could be one or more individual drafts -
>or by contribution of IETF-style text for the "ipdvb requirements" ID.
>This will assure, we have a common basis for discussion, either on the
>mailing list or (if issues do prove hard to resolve in this way) at the
>San Diego IETF. I'm anxious ULE collects only *useful* options.
>Note: These individual ID's could be very short (a few pages) and
>could finally be "combined" into the ULE (and/or requirements) text,
>should they be accepted by the group.
>
>(3) After production of a WG ULE ID, I'd like the WG to progress the
>charter item of adopting a requirements WG Internet Draft. This document
>must provide background, identify use-cases, and implementation options;
>leading to appropriate recommendations.  We can either start from the
>existing (somewhat imperfect/incomplete) requirements draft:
>
>http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt
>
>....or make one (or more) new ones. Thoughts?
>
>Gorry Fairhurst
>(ipdvb WG Chair)
>

---

From: William StanisLaus <[email-masked]>
Date: Wed, 10 Mar 2004 14:10:59 -0500

Hi Art,
	I apologize, hope there is a possible misunderstanding. I was supporting (b) 
as well.

<snip>
>(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.)
<snip>

which has caused misunderstanding.. to define the structure for extension bit 
is set.

Sorry for inconvenience again.

Best Regards,
William.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Allison, Art
Sent: Wednesday, March 10, 2004 11:56 PM
To: [email-masked]'
Subject: RE: ULE Extension Headers

William
I do not see how referring me to old posts without taking a position 
facilitates progress. I was not and am not attempting to reopen discussion. It 
seemed that it was time for preferences to be expressed. Given the 
clarifications and lack of continued objection; it seemed to me that maybe
(b) had enough support. So calling for a measurement of consensus seemed in 
order.

The alternatives that were clearly set forth by our esteemed Chair and are:

 'a', 'b', 'c' or 'no choice'.

So if each of us that cares asserts "I prefer (x)" or "for the reasons I have 
previously posted I  prefer (y)" we provide data upon which a way forward can 
be based. It is most reasonable to interpret silence is "I don't care".

I stated my preference. I urge helping the Chair to avoid having to report 'no 
choice' by stating yours.

Art
::{)>
Art Allison

-----Original Message-----
From: William StanisLaus [mailto:[email-masked]]
Sent: Wednesday, March 10, 2004 12:21 PM
To: [email-masked]
Subject: Re: ULE Extension Headers

Hi Art,
  Please refer the previous post on definition to the proposal (b) which 
describes the ext. bit.

Best Regards,
William.

On Wed, 10 Mar 2004 Allison, Art wrote :
>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:
>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)
>I don't wnat to stop any of this debate, but I would like to try and
>put a marker in the email threads so that those not following the
>detail of the various discussions, have a picture of where the group
>seems to have consensus.
>
>may optionaly 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:
>if the WG gets consensus, at the moment I see too many options and
>unclear concrete examples).
>
>ETSI documents). This could be one or more individual drafts - or by
>contribution of IETF-style text for the "ipdvb requirements" ID. This
>will assure, we have a common basis for discussion, either on the
>Note: These individual ID's could be very short (a few pages) and could
>finally be "combined" into the ULE (and/or requirements) text, should
>they be accepted by the group.
>
>charter item of adopting a requirements WG Internet Draft. This
>document must provide background, identify use-cases, and
>implementation options; leading to appropriate recommendations.  We can
>either start from the existing (somewhat imperfect/incomplete)
>requirements draft:
>

---

From: William StanisLaus <[email-masked]>
Date: Thu, 11 Mar 2004 13:24:34 -0500

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Gorry Fairhurst
Sent: Thursday, March 11, 2004 9:58 PM
To: [email-masked]
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" <[email-masked]> wrote:

> Allison, Art wrote:
> 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 ?
>
> maybe.
> Cheers.
> Alain.

---

From: [email-masked]
Date: Fri, 12 Mar 2004 12:10:14 +0100

Bernhard Collini-Nocker wrote:

> Hi,
> 
> in my opionion it is a good idea to think about both the D bit and the E bit
> again.
> The D bit is useful in those cases where a destination MAC address is
> requested for filtering/addressing purposes. It could be a Type value as
> well, altough this adds duplicate Types wrt to functionality.
> The E bit could instead be a Type value as well and only if the format of
> the header fields of the Ext header is not the same it could become a
> different Ext header.
> 
> The consequence of having no D and E bit but a Type value would be that the
> Type field could  be renamed to Next Header field, which it then essentially
> is. It would, however, require a different assigment strategy.

That is closed to what I proposed, and the pb I see, is that, with a
type/next header used to extension header, we have the same namespace
for both, and so the extension headers need to provide the "name" of the
next header (being and ext header or the payload itself). hence, each
extension header need 2 bytes to indicate what follows.
If we choose william strategy, the type field is linked to payload,
and extension header use a different name space, with only 1 byte to
identfy itself :
  - price : 1 bit in ULE header.
  - gain  : one byte per extension header.

Cheers.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com

---

From: [email-masked]
Date: Fri, 12 Mar 2004 12:14:17 +0100

Hi Sebastien,

 >  ... snip ...
 > and the current ULE definition needs additionnal fields to be usable
 > in a  meshed satellite system with on-board switching.

So you have concrete example of needed ULE additional fields,
please could you share ?

Thanks.
Alain.

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 12 Mar 2004 09:37:02 -0500

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

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Thursday, March 11, 2004 4:43 PM
To: [email-masked]
Subject: Re: ULE Extension Headers

On 11/3/04 6:02 pm, "Allison, Art" <[email-masked]> 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....

> Sent: Thursday, March 11, 2004 11:28 AM