[Css-csts] FW: Managed selection of prime procedure type

Tue Feb 8 11:13:10 EST 2011

Martin,

Thanks for your well-considered (as always) response. As I said, I was not in the session when this RID was discussed, and so my knowledge of that discussion has been limited to some quick fill-in later at the meeting itself, the text of the disposition of the RID, and the MoM. My proposal was triggered by the statements in the RID disposition (a) that the additional management was seen as a disadvantage, and (b) "To change prime procedure, the user shall unbind and bind again with a different SM configuration." 

I understand and appreciate your point - allowing multiple procedure types to be the prime procedure instance is a compromise between the technically/philosophically cleaner approach of having multiple simpler, focused services types vs. the politically-driven need to minimize the number of new service types. The RID disposition statement about changing prime procedures by unbinding and rebinding is misleading - if there is a possibility for a mission (MDOS) to use more than one prime version of a (multi-prime) service, multiple instances of that service, each supporting a single prime type, will be instantiated, and there will be no relationship between their individual bindings and activations. It's a much less dynamic situation than I was envisioning. I withdraw my proposal.

However, this does bring a question to mind. Should support for multiple prime procedure types be mandatory for all implementations of a service specification that includes such multiple types, or can it be left to the discretion of the specific service to define mandatory and optional conditions? This is not an issue for the FW itself but it will have to be addressed in the Guidelines.

Best regards,

John

ps - To answer your question about a User invoking a START with no instance number, the concept that I had was that there would be a prime procedure instance "in waiting" for that procedure type, and it would therefore start that prime procedure instance. Admittedly, for something like the Forward Frames service, this would imply that multiple production processes would have to be configured on the chance that their associated procedures would be activated, and that's not very realistic. But I was envisioning a perhaps broader range of potential services - e.g., a generic "Return Telemetry" that could have alternate prime procedure types for all frames, channel frames, or space packets. But other ways to handle such a situation (e.g., a more flexible set of selection parameters for the START operation).

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de] 
Sent: Tuesday, February 08, 2011 9:51 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] FW: Managed selection of prime procedure type

Dear John,

I do not really see how the approach you are proposing can be implemented without changing the FW. The general approach specified there is 

- all procedure instances that can be activated by the user must be specified in advance;

- conceptually the procedure instances are all created at the time the service instance is bound

- procedures are always identified by procedure type and number and the provider is required to check both the type and the number is a user request to verify that it relates to an existing procedure and that this procedure is in the state expected by the other side.

I always had a vague feeling of uneasiness with these specifications because I felt that the approach was rather static, but that is what has been agreed and there have been good reasons to do so.

To implement your proposal I think that as a minimum the check on the procedure instance number must be handled differently than in the current version of the FW. Beside that, I am afraid that there might be a number of issues related to such a change, which we currently do not yet fully understand. Taking your example: if all procedures have already been created and the user invokes START with no number, which one should the provider pick? If he picks #1 and the user subsequently invokes START with the number 1 is that an error? I assume that all could possibly work if all procedure instances were identical but I believe nothing in FW currently prevents a Service from using pre-configured instances, which would make them distinguishable. To implement your proposal, we might have to insist that all procedure instances are identical. But if all procedure instances of the same type are identical, why do we create them at the time of binding and not let the user "create" them with the first invoked operation? If we would create a procedure instance with the first invocation, then what would the state machine look like? etc.

If my memory serves me well, the main reason to have two potential prime procedure instances was that development of two different CSTSes to support a synchronous and a asynchronous forward frame services was considered politically unacceptable. On the meeting everybody seemed to say that these two options would never be used simultaneously for any mission. If that is true, I think the selected solution is appropriate and I would suggest not to introduce more complexity by trying to add more flexibility.

Kind Regards,

Martin

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 08 February 2011 14:36
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] FW: Managed selection of prime procedure type

CSTSWG colleagues ---

The disposition of CSTS FW Red-1 RID NASA-TJR-06 states:

"Proposed approach:

1. The service is defined allowing more than one procedure instance to be prime;

[2]. The prime procedure identification (among the candidates one identified by the service) is done by SM;

[3]. To change prime procedure, the user shall unbind and bind again with a different SM configuration."

I did not participate in the discussion that led to this decision, but I am happy with the main point - that more than one procedure type can be designated as the type that can be used for the prime procedure instance. However, instead of having the selection managed and requiring a separate service instance to be established for every prime procedure type that the user might wish to use, I wonder if the WG considered what I think is a simpler approach - to let the user dynamically identify the prime procedure instance by whether or not an instance number is specified in the procedure-instance-identifier of the first operation invoked in the context of the procedure instance. This would eliminate the need to create multiple service instances if the user might need to use different prime procedure types. Given that the only reason to designate a procedure instance "prime" is to set the state of the service (that is, it has no effect on the functionality of the procedure instance), this seems to me to be something reasonable to consider. 

For example, assume that two procedure types, ProcA and ProcB, can host the prime instance, and other secondary procedure types can be specified. Both ProcA and ProcB are stateful and set their state via START/STOP. The service also allows up to N secondary instances of ProcA and M secondary instances of ProcB. The user STARTs ProcA with no instance number before STARTing ProcB. ProcA is dynamically designated the prime instance. Any time after starting the prime instance of ProcA, the user can START and use the secondary instances using instance numbers 1-N.  Any time after starting the prime instance of ProcA, the user can START any of the secondary instances of ProcB using instance numbers 1-M. If the user attempts to send any ProcB PDU (including the START invocation) with no instance number, the service is peer-aborted because ProcA has already taken the prime procedure instance "token". The user can STOP the ProcA prime procedure (which also moves the state of the service instance to 'bound.ready'), at which point ProcA could be used again as the prime procedure instance, or ProcB could be started as the prime procedure instance.

The record of the discussion regarding this RID notes that there was a concern about additional burden on Service Management. This approach places no additional burden on SM.

As Yves has already discovered and noted in the status for this RID, the current disposition (having the prime procedure type selected via SM)  has no effect on the FW, but it will on the Guidelines and Concept. The variation that I propose also has no effect on the FW, but will have an effect (a different one, of course) on the Guidelines and Concept.

Does anyone else see a benefit (as I do) to this modified approach, and would the WG be willing to consider it instead of the SM-controlled selection approach?

Thank you.

Best regards,

John

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110208/1d08086b/attachment.htm