Re: ULE Extension Header Thoughts - Mandatory extensions

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

Hilmar, William, other people on the list, can I make some comments as a 
WG Chair and solict feedbacok from the list:

I'm first trying to work out if there are potential issues when the 
ordering of Mandatory Extension headers could result in reduced 
inter-operability (i.e. Where a receiver will fail/behave unexpectedly 
because of the ordering).

William StanisLaus wrote:

> Please see my response inlined...
>
>
> > -----Original Message-----
> > From: owner-ipdvb@erg.abdn.ac.uk 
> > [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Hilmar Linder
> > Sent: Monday, June 28, 2004 12:58 PM
> > To: ip-dvb@erg.abdn.ac.uk
> > Subject: ULE Extension Header Thoughts
> >
> >
> > when thinking about the extension headers for ULE we left several 
> > questions untouched in the first draft. Therefore, I would 
> > like the list 
> > to comment on the following items:
> >
> > o) Should we define the chaining mechanism: All mandatory extension 
> > headers MUST/SHOULD be inserted by the encapsulator prior to any 
> > extension headers in order to optimize receiver processing. A 
> > receiver 
> > is such able to discard a SNDU whose mandatory extension 
> > header is not 
> > supported or is to be rejected without having to investigate and 
> > eventually process optional extension headers beforehand.

Agreed, if an operator chose to do this it could be a waste of 
processing resources to process extension headers belonging to a PDU, 
and then ultimately discard that PDU. If the first extension was always 
present in all SNDUs however, teh cost of processing could be reduced by 
pattern-matching the headers (as in TCP header prediction), so the cost 
need not always be as much as it seems.

> William> It MUST be implemented all mandatory headers before any
> optional headers and actual data. Since at any cost if mandatory header
> is not supported/implemented the receiver MUST drop the SNDU. Inserting
> optional header before mandatory headers will give room to unnecessary
> processing.

Normally when the IETF mandates MUST be implemented, it implies an 
interoperability issue. A good ethos is for receivers to liberal in what 
they receive (that way we avoid painful discoveries when new uses appear).

* I wonder though if this is really an inter-working issue, or purely an
optimisation that a gateway could use, in the same way the NPA address 
can be used as a pre-filter or not, depending on topology, bandwidth 
cost, etc. In other words, what breaks if we allow arbitrary ordering?

* Another issue is what we could we loose by requiring specific ordering?

If there are potential issues where this results in reduced
inter-operability (i.e. Where a receiver will fail because of the 
ordering) then I think we should specify - If there are only 
performance-related issues then we could identify these, but I'd urge 
being liberal in what the Receiver should accept - 
implementers/operators can still optimise Receivers for the most common 
code-path.

<snip>

Gorry
ipdvb WG Chair

-------------- ipdvb list -------------------
To unsubscribe from the ipdvb list :-
Email majordomo@erg.abdn.ac.uk with the words
unsubscribe ipdvb
in the body of the message.
http://www.erg.abdn.ac.uk/ipdvb/
---------------------------------------------