Re: Call for the ipdvb WG to adopt: draft-fairhurst-ipdvb-ule-ext-01.txt

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

Hello together.

I strongly believe that the ipdvb WG should adopt this draft.

I also have a few comments(C)/suggestions(S) (see below).

===
(S.1) Regarding the PDU-Concat Extension:
Maybe we can somehow use the (currently unused) most-significant bit in the first byte of they PDU-Length field?
Of course, as nothing comes for free, every possible use of it will complicate the receiver processing.
Nevertheless, we should consider it. My suggestions are:

	(a) It could be used to selectively enable a type field for each concatenated PDU, i.e. sort of "Type Field present indicator" (denoted by T). Of course it could also be an "absent indicator" ;-). From now on, I'll denote the PDU-Length field along with the optional type field as "concat header". The first concat header must have T=1 to indicate the type of the payload. After that one, if in subsequent concat headers T=0 then the the type field is omitted and the type is the same as indicated in the last concat header which had a type field (T=1).
This also gives us the option to use extension headers in concatenated PDUs. The question is if we should allow them.
I might add that using the T-bit would make the CONCAT-PDU-Type of the current draft version unnecessary.

I also discussed this point with Gorry. It would be glad if we could get some comments on this one.

	(b) We could also use the MSbit for padding purposes, i.e. to achieve alignment (e.g. 2- or 4-byte) for the concatenated PDUs.
The bit (P) would then control the presence of a padding control byte right after the PDU-Length field. The content of this padding control byte (PDU-Pad)
is interpreted as the number of (additional) padding bytes (containing the hexadecimal value 0xff) preceding the start of the concatenated PDU.
Example:
If P=1 and the PDU-Pad field has a value of 2, this means that 2 bytes of padding follow the padding control field. This means that in total the PDU is padded by 3 bytes (including PDU-Pad).

If PDU-Pad=0, then we've a 1-byte of padding.

(S.2) Regarding the TS-Concat Extension
In section 3.1 it might be more clear to refer to the number of TS packets contained in the SNDU by name, e.g. TS-Count, defined as
	TS-Count := (Length-10+D*6) / 188


(S.3) The figures on page 9 and 10 may suggest that the concatenated PDUs are aligned, but in fact they're not.

(C.4) Regarding the "Summary" section (4)
I never heard the term "Next_Header options" before.

(C.5) Typos

Page 3:

> to this document. GSE maintains a design philosophy that presents a 
> common network interface to that of ULE and uses a similar 
> construction for SNDUs 
                       ^--- A dot is missing

Page 8:
> The base header contains the Length of the entire SNDU. This carries 
> the value of the combined length of all PDUs to be encapsulated, 
> including each set of encapsulation headers. The base header also 
> caries a 16-bit ULE Type field.
    ^--- Don't remember me on my next visit to the dentist ;-)
===

Looking forward to hear from you.

Best regards,
Christian.
--
Christian Praehauser <cpraehaus@cosy.sbg.ac.at>
Department of Computer Sciences, University of Salzburg