[Css-csts] SLE RAF permitted-frame-quality-set managed parameter

[Barkley, Erik J (3170)]

Finally catching up with this thread, I will only add that the fact that this emerged as a managed parameter in B-3 tends to tell me that it is not by mistake that it is there (its seems like real-world implementation experience has to have been taken into account).    John's assessment re updating for B-4 looks good to me.

-Erik

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Thursday, January 31, 2013 6:39 AM
To: Stoloff, Michael J (318D)
Cc: Fabienne.Delhaise at esa.int; Martin Götzelmann; CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: RE: [Css-csts] SLE RAF permitted-frame-quality-set managed parameter

Michael,
Thanks. I note that the definition of 'unable to comply' is "the provider is unable to transfer data at this time because of a fault affecting the provider", so it's application in this situation is technically dubious (but I understand that you have to go with the diagnostics that you've got).

Members of the CSTSWG - From Michael's emails it seems clear that the RAF service should formally support SM constraints on the value of the requested-frame-quality parameter. Until the last revision of the RAF Blue Book (B-3), the permitted-frame-quality-set was not even identified as a managed parameter, and although it *is* so identified in table 3-1 of B-3, there is no other mention of it in the book. There are already a number of "RIDs in waiting" for the SLE books. I think another one is in order for RAF B-4, i.e., to explicitly state that the requested-frame-quality parameter must conform to the permitted-frame-quality-set managed parameter, to add a new diagnostic specific to this purpose (and not have it piggy-back on the not-quite-appropriate 'unable to comply'), and (secondarily) add permitted-frame-quality-set to the list of parameters gettable via RAF-GET-PARAMETER.

Best regards,
John

From: Stoloff, Michael J (318D) [mailto:michael.j.stoloff at jpl.nasa.gov]
Sent: Thursday, January 31, 2013 6:36 AM
To: John Pietras
Cc: Martin Götzelmann; CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)
Subject: Re: [Css-csts] SLE RAF permitted-frame-quality-set managed parameter

The RAF-START invocation is rejected with the diagnostic, "Unable to comply."

On Jan 30, 2013, at 12:59 PM, John Pietras wrote:

Michael,
Thanks for your response on this. The issue came few weeks ago out of SGSS, where implementers realized that there is no START diagnostic corresponding to a user attempting to START an RAF service instance with an unapproved value in the requested-frame-quality parameter. I was not able to trace the managed parameter back to anything that arose from the RAF service itself and assumed that it was something that we had erroneously include in SM without corresponding support from the RAF spec.

So, what does the DSN implementation do when a user asks for all (good and erred) frames when the permitted value is good frames only?

By the way - there is no intent to remove the RCF permitted-global-VCID-set parameter - there's a diagnostic defined for when that fails and its value can be retrieved via the RCF-GET-PARAMETER operation.

Thanks again for your help.

John

From: Stoloff, Michael J (318D) [mailto:michael.j.stoloff at jpl.nasa.gov]
Sent: Wednesday, January 30, 2013 3:43 PM
To: John Pietras
Cc: Martin Götzelmann; CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>); CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); Barkley, Erik J (3170); Firre, Daniel E (9020-Affiliate)
Subject: Re: [Css-csts] RE: SLE RAF permitted-frame-quality-set managed parameter

John,

Please do NOT remove the RAF permitted-frame-quality parameter (or the corresponding RCF permitted-virtual-channel parameter) from the list of SLE "managed parameters."  As a matter of fact, both the NASA/DSN and the ESA/ESOC implementations of (non-standard) SLE service management have operational configuration tables that permit the management of both those parameters, as I believe was the original intent both of RAF and RCF.  Real world service providers need to worry a great deal about quality-of-service and other important details that are essential to satisfying our customer's needs.  The above two managed parameters are an essential mechanism that enable providers to control QoS that may need to vary between service instances, due to either mission requirements or cost effectiveness.  For that reason, both DSN and ESOC have published configuration table specifications that require those parameters, and some of those configuration tables have been in place since SLE first became operational in the DSN in CY2002.

I did a quick skim of the RAF and RCF specifications, and I would agree that the requirement for these two managed parameters is not well specified.  Nonetheless, I would argue that there are some hints in the Blue Book text that it was intended that these should be managed parameters, and I would also testify to the CCSDS working group discussions in which that intention was explicitly stated.  The fact that both NASA/DSN and ESA/ESOC have implemented both parameters as managed parameters, using the same language (e.g., requested- vs. permitted-frame quality, etc.) is further testimony to the original intent (and continuing need).

I strongly recommend that you check with ESA/ESOC before making any changes.

--Regards,
  Michael Stoloff
  NASA/Jet Propulsion Laboratory

On Jan 30, 2013, at 12:18 PM, John Pietras wrote:


Martin,
Thanks for your response. My apologies for not making my question to you more obvious.

I will take this as confirmation that it was incorrect to put this as a managed parameter in Service Management, and the error was compounded by copying it into Table 3-1 of the RAF service specification.

CSSMWG colleagues --- I'm going add removal of the permittedFrameQualities parameter from the RafTransferServiceProfile data set to the list of corrections to be made as part of the Technical Corrigendum to B-1 that we are planning to create.

Best regards,
John

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Wednesday, January 30, 2013 6:07 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>)
Subject: RE: SLE RAF permitted-frame-quality-set managed parameter

Dear John,

I just noticed that your e-mail includes a question to me - sorry for the delay in answering.

I checked once more and I can confirm that the RAF API specification has no knowledge of a permitted-frame-quality-set . In the recent update I have made to align the API with RAF B-3, I have only checked for implications on the interface to the user. As the permitted-frame-quality-set is not gettable and the START diagnostics had not changed this change did not make it into the proposed API Update.

Regards, Martin

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 16 January 2013 00:19
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>)
Subject: [Css-csts] SLE RAF permitted-frame-quality-set managed parameter

CSTSWG and CSSMWG colleagues ---
The NASA Space Network Ground System Sustainment (SGSS) Project has uncovered an ambiguity (and possible error) in the SLE RAF specification, CCSDS 911.1-B-3. This ambiguity/error is likely the result of something in the Space Communication Cross Support Service Management (SCCS-SM) specification (910.11-B-1) so I'm also including the CSSMWG on this message.

The ambiguity is as follows: Table 3-1 of the RAF specification lists the parameter permitted-frame-quality-set as a parameter that is set by Service Management. This parameter did not appear in the Blue-1 and Blue-2 versions of the RAF specification, but was added to B-3 to be consistent with the SCCS-SM specification, which has a permittedFrameQualities parameter as part of the configuration profile information for RAF transfer service instances. The concept of the permitted-frame-quality-set (permittedFrameQualities) parameter is that it would be set via Service Management to constrain which frame qualities (good-frames-only, erred-frames-only, or all-frames) could be requested in the requested-frame-quality parameter of RAF-START invocations for that service instance. However, as pointed out by the SGSS team member, there is no diagnostic for a failed RAF-START to indicate that the requested-frame-quality parameter contains a value that is not consistent with permitted-frame-quality-set.

I believe that the RAF service was not originally intended to allow Service Management to limit the values of frame quality that could be requested via the RAF-START operation. However, in Service Management we created such a managed parameter. Before the 2010 update of the SLE books, the Tables 3-1 of those books contained most but not all managed parameters that had been documented in SCCS-SM. When Wolfgang updated the SLE books in 2010, he wanted to make the managed parameters in the Tables 3-1 consistent with the SCCS-SM specification, and I supplied him with a list of the parameters that were missing, including the one related to limiting the options for the value of the permitted-frame-quality parameter. For whatever reason, the fact that this constraint was never enforced by the RAF service in terms of a defined negative result and diagnostic value somehow slipped by all of us.

So there are two possible approaches, from which we have to pick one:
1.       The first possible approach is that the RAF service DOES NOT allow Service Management to pre-constrain the frame qualities that a user can request via the requested-frame-quality parameter. That is, all RAF instances will always allow the user to request all frames, good frames only, or erred frames only. If this is the approach selected, then the permitted-frame-quality-set parameter needs to be removed from table 3-1 of the RAF specification and the permittedFrameQualities parameters need to be removed from the SCCS-SM specification.
2.       The second possible approach is that is that the RAF service DOES allow Service Management to pre-constrain the frame qualities that a user can request via the requested-frame-quality parameter. If this approach is selected, then the permitted-frame-quality-set parameter stays in table 3-1 of the RAF specification and the permittedFrameQualities parameters stay in the SCCS-SM specification, but a diagnostic needs to be added to the negative result for the RAF-START operation to indicate that the requested frame quality is not supported by the configuration of the service instance.

My guess is that the correct approach is (1) - that is, that the DTSWG/CSTSWG did not intend for an RAF service instance to be constrained by management as to which qualities could be requested. But I don't know for certain and so I am asking the opinion and knowledge of other members of the WGs to please contribute to the conversation. Does anyone know of an RAF implementation that supports the such a constraint? Martin Goetzelmann - does the RAF API say anything one way or the other on this topic?

Thank you all for any comments that you can provide.

Finally, If the decision is to take approach (2) - that is, to keep permitted-frame-quality-set/permittedFrameQualities as a manage parameter - then the allowed values for permittedFrameQualities in tables 5-81 and 5-94 of SCCS-SM must be modified in a future Technical Corrigendum to remove the value 'undefined'. This value was added to the possible values to support the delivered-frame-quality  'undetermined' value, but this value is unnecessary since the 'all frames' value is used to also specify that frames can have the  'undetermined' quality value (see the NOTE in section 3.6.2.6.1 of the RAF spec), and in fact it has been removed from the permittedFrameQualities parameter in E-06.

Best regards,
John

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org<mailto:Css-csts at mailman.ccsds.org>
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130206/0c815ebc/attachment-0001.htm