Limitation of nonStandardData

[Pete Cordell]

Douglas, I couldn't have said it better...

As far as constraints and SETs etc....

Paul, It's funny you mentioned 32MB because that's exactly how big an
H.245 structure came out when we compiled it!  Perhaps we did something
wrong, but now we have gone to linked lists and its all hunky dory.  My
feeling is that if you use the fixed size constraints you are guaranteed
to waste memory in systems that can't afford to waste it.  What you need
is a size constraint for the entire decoded message.  Unfortunately
ASN.1 does not give you such a feature.

Woops, I have to take back what I said about the encoding of SET OF.  It
came from my hazy memory of the following paragraph from X.691:
21      Encoding the set-of type
21.1    For CANONICAL-PER the encoding of the component values of the
set-of type shall appear in ascending order, the component encodings
being compared as bit strings padded with as many as seven 0 bits to an
octet boundary.
NOTE - Any pad bits added to achieve octet alignment for the sort do not
appear in the actual encoding.
21.2    For BASIC-PER the set-of shall be encoded as if it had been
declared a sequence-of type.
However, we are using the BASIC for so there shouldn't be a problem.

For what it's worth, I agree that ERROR propagation is not a good thing,
but, based on the premise that exceptional cases introduce bugs,
SUB-OPTIMALITY propagation is not always a bad thing if it leads to
consistency!!!

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Douglas Clowes[SMTP:dclowes at OZEMAIL.COM.AU]
>Sent:  04 December 1997 01:22
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Limitation of nonStandardData
>
>Paul,
>
>There seems to be a mismatch in the understanding here and I'm not sure
>that it isn't me. So I'll give my version the understanding and hope to
>be
>corrected where I'm wrong. (BTW, I don't understand what the '...' in
>the
>ASN.1 does and why it's in the middle of the H.323 V2 stuff.)
>
>At 13:25 3/12/97 -0800, Paul Long wrote:
>>Pete Cordell wrote:
>>> We are mainly interested in gatekeepers.  We have a need to ship
>>> nonStandard information between cooperating gatekeepers, particularly in
>>> the SETUP message.
>>
>>Okay, I see that H.225.0 apparently wasn't engineered for multiple
>>nonStandardParameters, whereas H.245 at least originally was, but at a
>>higher level, not merely a SET OF NonStandardParameters. I agree that
>>this is a problem in H.225.0, but I don't think there is a problem with
>>H.245, unless someone can give me specific examples.
>>
>
>The problem tends to arise in a channel where there are multiple nodes.
>This could be true of RAS if there is a hierarchy of gatekeepers. It is
>true of of the Call Signalling Channel and the H.245 Control Channel
>when
>going via one or more gatekeepers, proxies or other devices.
>
>An obvious problem arises in the following situation. Two endpoints
>require
>a NonStandardParameter in the Q.931 SETUP message so that they can
>cooperative complete a connection. Two intermediate (to the endpoints)
>and
>cooperative gatekeepers require to add a NonStandardParameter for their
>participation in the SETUP process. Two intermediate (to the
>gatekeepers)
>and cooperative proxies require to add a NonStandardParameter for their
>own
>use. The problem arises when the intermediaries throw away the
>NonStandardParameter already in the message and substitute their own
>because the syntax only allows one NonStandardParameter.
>
>I don't understand how H.245 intrinsically solves this problem for,
>say,
>OpenLogicalChannel.
>
>>> To do this, I propose that the piece of ASN.1 put in the data part of
>>> nonStandardParameter should be:
>>>
>>> ExtendedNonStandardData ::= SEQUENCE
>>> {
>>>         previousNonStandard     NonStandardParameter OPTIONAL,
>>>         extraNonStandard        SEQUENCE OF NonStandardParameter,
>>>         ...
>>> }
>>
>>Please constrain this aggregate with something like this:
>>    extraNonStandard     SET SIZE (0..255) OF NonStandardParameter,
>>
>
>Given that a NonStandardParameter contains a data field that is an
>unconstrained OCTET STRING, I don't see the point of arbitrarily
>constraining the number of them.
>
>>> A V1 endpoint could put its own piece of nonStandardData into the
>>> existing nonStandard field.  When a gatekeeper (or something else)
>>> received it, it would take the data from the existing nonStandard field
>>> and put it in the previousNonStandard field of the above SEQUENCE.
>>
>>Copying it or moving it? IOW, would the original nonStandardData still
>>be present?
>>
>
>The original nonStandardData is moved, by the first gateway of the
>above
>example, into the previousNonStandard field. This allows the first
>gateway
>to add its own NonStandardParameter to the extraNonStandard field.
>
>The whole ExtendedNonStandardData is placed in the data field of the V1
>NonStandardParameter which is included in the original message in place
>of
>the original nonStandardData.
>
>The first proxy does exactly the same thing.
>
>The message is still V1 compliant so if it goes through anything else
>that
>cares, it still sees a standard V1 message with the single
>NonStandardParameter allowed in the standard and, hopefully, passes it
>on
>to the second proxy.
>
>The second proxy recognizes the NonStandardparameter as its very own
>and
>unwraps it to reveal, in the previousNonStandard field, the
>NonStandardParameter that the first proxy received from the first
>gatekeeper. It takes its own stuff out and restores the
>NonStandardparameter from the previousNonStandard field, places it in
>the
>outgoing message as the one and only NonStandardParameter allowed in
>the
>message and sends it to the second gatekeeper.
>
>The second gatekeeper does exactly the same thing. The message that it
>sends to the second endpoint contains the original (from the first
>endpoint) NonStandardparameter as received by the first gatekeeper.
>
>>> It would then add whatever nonStandard stuff it needed to the
>>> extraNonStandard bit.  It would put the combined nonStandard data in the
>>> data part of the nonStandardParameter and give it the tag that we decide
>>> on.
>>
>>I don't understand, why have "previousNonStandard?" Why not just have a
>>single nonStandard SET SIZE (0..255) OF NonStandardParameter, and simply
>>append any GK stuff to the end? Also, as someone said previously in this
>>thread, what if a third-party stack uses the single, original
>>NonStandardParameter, yet the layer above that stack also wishes to
>>include NonStandardParameters. Sounds like NonStandardParameters can be
>>added and removed at any point in the data path, not just by GKs.
>>
>
>In V1, there is only a single nonStandard, not a set of them. To
>include a
>NonStandardParameter where there alreay is one requires the original to
>be
>discarded which is the root of the problem. To extend the standard to
>have
>a SET or SEQUENCE OF is a possible solution to the problem. If the
>message
>goes through something that only tollerates a single
>NonStandardParameter
>as specified in the standard, there could be a problem.
>
>[cut]
>
>>> I've used an unconstrained SEQUENCE OF for the following reasons:
>>> 1. No other SEQUENCE OFs are bounded within H.225.
>>
>>They should have been, and this will cause implementation problems down
>>the line. Each vendor guesses what the max should be. Although all
>>guesses are equally "correct," some will be too low and could cause the
>>system to fail through no fault of the vendor. Remember that not all
>>implementations will have 32MB of RAM and all the virtual memory they
>>need.
>>
>
>I understand your concern but, again, the NonStandardParameter is
>unbounded
>(if I correctly interpret 'OCTET STRING') and so, limiting the number
>of
>them to 255 doesn't add a lot and imposes an arbitrary constraint.
>
>>> 2. Size constraints on SEQUENCE OF are not always that useful
>>> (especially in the case of H.245!)
>>
>>I have no idea what you mean by this. There are always real size
>>constraints--no system has infinite resources. It would just be nice if
>>the constraints were agreed upon and stated up front in the
>>Recommendation.
>>
>
>If you impose limitations that fit the lowest hardware of today, they
>will
>be innappropriate for the hardware of this afternoon. If you set the
>limits
>to handle the growth, does it help today. Say we imposed a limit of a
>4GB
>today, would it help. If we made that limit 16K today, how would that
>impact us later?
>
>>> 3. We have no other SET OFs in H.225
>>
>>So error propagation is a good thing, right? :-)
>>
>
>This bit I agree with, so it probably means I don't understand the
>finer
>points of difference between sequences and sets, right? :-)
>
>>> 4. As I understand it, for some strange reason, because the order of the
>>> members of a SET OF is intended to be un-important the compiler takes it
>>> upon itself to sort the values entered into some form of order!!!  This
>>> seems a waste of time and is a step best avoided by using SEQUENCE OF.
>>
>>I've never heard of this before. I'll check with Bancroft. Sounds like a
>>bug in the OSS compiler, which by the way we don't use for reasons like
>>this.
>>
>
>Sounds like a problem with implementation in a particular compiler, not
>a
>good basis for setting the direction of a standard. I think that the
>*best*
>way to avoid such a problem is to fix or replace the compiler.
>
>
>Regards,
>
>Douglas Clowes
>