Re: Speeding up the stack - Alternative Encoding Rules.

[Peter Furniss <[e-mail]>]

> > I think this is on track!
> 
>    Hmm. If this is the case I definitely think it should be an item in
>    the thinOSI stack IETF WG agenda, If it isn't already.

I meant it was inbounds generally, and the choice of encoding in the 
cookbook is definitely part of the review of its current draft. I don't have
a clear enough idea of what to do next though.

The SC21 WG8 Presentation group in Yokohams produced, amongst other
things, a "First working document on Lightweight Encoding Rules" and a
liaison statement, sent to several groups (but not ietf !) "Liaison
re: Proposed resolution of remaining ASN.1 efficiency problems". I
will try and get these made electronically accessible.

>   I think a think stack will also require good ASN.1 compilers or minimising the
>   overhead of ASN.1 encoding (preferable both).
> 

Depends what you include in the stack. The cookbook doesn't include
the application data (at present - if the thinDAP part is ever done,
that would include the application)

> .....
> 
>    Another issue s wether start up and tear down time for an OSI connection
>    can be improved.
> 
>    i.e. You must make a Network connection, A Transport Connection and finally
>    an ACSE/Presentation connection.
> 
>    Thus if D is the delay to send info from one end to the other we are
>    talking 6D !
> 
>    This could quite bad . Is it possible for you in your position in the standards
>    committee to suggest a fast or compressed start up? i.e. If the Network entity
>    sends a N-Connect with special user data which is a compression of the
>    parameters needed to set up a TYPE I connection? Does N-Connect carry user data?
> 
>    or Perhaps T-Connect could carry a special compressed connection packet for
>    the stack. Perhaps a special t-selector could select which type of stack it
>    wants? This could be defined by an RFC? perhaps a special port. Am I right in
>    understanding that Transport Connection which can carry user data is not used
>    in the session establishment?

There is already a proposal in SC6, called "fast-byte" with precisely
this intent. The fixed encoding discussion in Yokohama was triggered
by a US input that referred to that and was also inspired by thinosi.
Not being involved in SC6, I am not sure how well that is progressing,
but I believe it has substantial ITU-TS (ex-CCITT) interest.

(If the network-layer is CLNS (and if TUBA is the IPng, it probably
will be) there is no N-CONNECT. The problem then is just that
T-CONNECT user data is limited to (I think) 128 octets - this makes
negotiation down to TP0 straight-forward, but is very silly if the
network packets are 1400 octets anyway. If that limit is increased,
piggy-backing S-CONNECT, P-CONNECT, AARQ and user-initialisation is
reasonable.)

An additional element (also mentioned in SC21 somewhere) is that it
can be sensible to make the start-up exchanges non-blocking - so you
send data before the accept comes back. If it isn't an accept, the
data is lost, but then it wouldn't have been received anyway. At
present OSI is very conservative in this area.

Peter