FYI: comments on the document draft-ietf-ipdvb-ule-ext-01

[Christian Praehauser <cpraehaus@cosy.sbg.ac.at>]

Hello everybody!

This mail sums up my comments on the extension formats defined in the 
document draft-ietf-ipdvb-ule-ext-01, which I already presented at the IETF Meeting in Prague.
Note: The following text basically rephrases my slides which can be obtained at
http://www3.ietf.org/proceedings/07mar/slides/ipdvb-5.pdf.

PDU-Concat
==========
The encapsulator has to wait a certain time until enough PDUs have been aggregated. This might influence link characteristics, e.g. jitter.
It may be wise to add a „Notes to Implementors“ section to address these (and maybe other) issues.

With PDU-Concat, we hopefully get bigger SNDUs, which reduces the protocol- and processing overhead. However, this also
makes the SNDUs more sensitive to bit errors caused by the link. Thus, PDU-Concat might not be appropriate on links with high bit error rates.

The CONCAT-PDU-Type field may indicate further ULE extensions. Are these extensions then applied to the whole SNDU or should they be applied to 
each PDU that is contained? Some extensions may apply to a specific PDU, e.g. Timestamp extension, provided that the timestamp indicates the time 
at which the PDU was received by the encapsulator. Also, considering ULE security extensions, it may be possible to define security policies based on IPv4/IPv6 source-/destination addresses.
Maybe someone knows of other extensions which apply specifically to one PDU.

The question is: should PDU-Concat be flexible enough to support this?
My suggestion was to use the (currently unused) MSB of the CONCAT-PDU-Length field as a "T-Bit".
For further information on the T-Bit thing, see the mail from Gorry with the subject "PDU Concat specification - design options we could explore".

TS-Concat
=========
How should TS packets that are transported over ULE (using TS-Concat extension) be delivered at the receiver?

Injecting the stream (at the receiver) into the same multiplex where the ULE stream is received raises at least one (security) issue:
What to do if a encapsulated TS stream interferes with an existing stream in the multiplex (PID collision)?
Can we detect it at the receiver? Can we detect/avoid it at the encapsulator? If the encapsulator is an independent system, it probably doesn't
even know what other streams (PIDs) are present on the multiplex.

Timestamp
=========
Regarding the semantics of the timestamp: how should the value of the timestamp be interpreted by a receiver?
	* The time when the PDU has been received by the encapsulator
	* The time when the SNDU was transmitted by the encapsulator
	* Not defined?

What about an extension for just allocating space in the SNDU for a timestamp and let hardware fill it in (Hardware-assisted Timestamping)?

Kind regards,
Christian.

--
Christian Praehauser <cpraehaus@cosy.sbg.ac.at>
|| //\\//\\ || Multimedia Communications Group,
||//  \/  \\|| Department of Computer Sciences, University of Salzburg
http://student.cosy.sbg.ac.at/~cpraehaus/
http://www.network-research.org/
http://www.uni-salzburg.at/