[Css-csts] tracking data recording buffer retention issues

Tue Mar 1 13:47:23 UTC 2016

Dear Margherita,
Thanks for the quick response. I agree that further discussion and brainstorming at Thursday's telecon is a good idea, but I'd like to respond to one aspect of your comments here. The Recording Buffer exists and persists outside the lifetimes of individual CSTS service instances. Furthermore, in general (and also in the specific case of the tracking data service), the Recording Buffers can be accessed by multiple CSTS instances simultaneously or asynchronously. Beyond that, the Mission may need to change the operating characteristics of a Recording Buffer when there is no active Space Link Session Service Package. So I think that managing/controlling the Recording Buffer through a TD CSTS instance is not a viable mechanism.

The Service Control service would be one way for the Mission to control the operation of a shared resource such as a Recording Buffer, but the SC-CSTS will still be limited to being available only during the execution of a Service Package of some sort. So how a Mission might adjust the operating characteristics of a resource "between" the executions of Service Packages is something that has not yet been addressed, even in Service Management. Note that there *is* a mechanism for setting the initial values for such resources - the Service Agreement. What I am talking about here is making subsequent adjustments to such settings.

The above discussion is about *how* such parameters could be changed, but my original question was even more basic than that - it was whether for TD-CSTS we should even try to identify what "parameters" make sense to control such things, or simply do what the SFW does and state that it is outside the scope of the standard. If we take the SFW approach, that allows the CSSMWG to either ignore it or to decide to address it in a systematic manner. But if we declare in the TD-CSTS book that it is managed by SM then we essentially require the CSSMWG to decide which parameters are needed and how those parameters are managed/controlled.

I('m looking forward to discussing this on Thursday.

Best regards,
John

From: Margherita.di.Giulio at esa.int [mailto:Margherita.di.Giulio at esa.int]
Sent: Tuesday, March 01, 2016 5:11 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] tracking data recording buffer retention issues

Dear John,

We can certainly bring this point to discussion in the next WG Telecon on Thursday.

My first thought is that, whenever something gets handled by Service Management, it becomes rather "static". This approach should be taken for any characteristics of a service that holds for the whole mission.
Assume the parameter "minimum retention period" gets assigned by SM to the TD CSTS Service Instance.  In case a User needs to change that value the only way out is to disconnect from the presently active Service Instance, create a new SI with the desired value, activate the SI,  and connect to it.
If instead one envisages a more dynamic behaviour, it would be preferable to leave the handling of the parameters to the Service itself ( e.g. the value  can be queried and can be configured by means of a directive).

The next point I have is: shall a Provider (typically a Ground Station) manage one such buffer per each supported mission, and shall therefore foresee that set of parameter for each buffer, or will there be a unique buffer?

Are the above issues something we should address with the NAV experts?

We'll brainstorm about it at the telecom.

Kind regards,
Margherita

--------------------------------------------------------------
Margherita di Giulio
Ground Station Back-end Section (HSO-GIB)

European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int<mailto:Margherita.di.Giulio at esa.int>

From:        "John Pietras" <john.pietras at gst.com<mailto:john.pietras at gst.com>>
To:        "CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)" <css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>>
Date:        29/02/2016 22:14
Subject:        [Css-csts] tracking data recording buffer retention issues
Sent by:        css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>

________________________________

CSTSWG colleagues ---
I have been making the final synchronizations between the TD-CSTS and the latest SFW. I believe that I have made almost all of the necessary adjustments, with the following exceptions.

The current TD-CSTS specifies that the following be established by Service Management:
a.       the size of the recording buffer;
b.      minimum period that the TDM Recording Buffer is required to retain the stored data before it is automatically purged; and
c.       overflow policy that shall be applied when new tracking data is available to be stored but the TDM Recording Buffer is full

The current TD-CSTS goes on to state that the parameter that specifies the size of the recording buffer (tdmRecordingBufferSize)is queriable.

The latest (and we hope final, at least for now) SFW specifies that that every CSTS that a "Functional Resource Type representing a recording buffer shall have a queriable recording-buffer-size parameter that specifies the storage capacity of the recording buffer" (CSTS SFW 4.5.7.9). However, the CSTS SFW is mute on the subject of how the recording buffer size is configured.

Also, the NOTE under 4.5.7.5 (a) states "The time span over which data is retained in the recording buffer, the policy for deleting data from the recording buffer, and the conditions under which the recording buffer begins to accept data following an overflow condition are outside the scope of this Recommended Standard. In general, service provider and service user will agree on a data custody transfer protocol."

Regarding the recording buffer size, I propose that we continue to have the TD-CSTS specify that tdmRecordingBufferSize is not only the parameter by which the buffer size is queried, but also the parameter by which is it configured.

Regarding the minimum retention period and overflow policy, the question that I have is whether stating that the minimum retention period and overflow policy are "established by Service Management" is consistent with the SFW's treatment of these topics, which says that it is outside the scope of the SFW, other than to say that that the service user and service provider will come to some agreement. Even though the TD-CSTS doesn't say how Service Management establishes them, our general concept has been that by saying something is handled by Service Management means that the CSSMWG is expected to establish some standard way for doing so. Are we okay with such an approach, or should we soften the wording even in the TD-CSTS to match the SFW approach, such that such decisions could even be made outside the scope of CCSDS-standardized Service Management?

If we have a few minutes to discuss this during this coming Thursday's telecon, I would appreciate it. I would like to be able to go into the Cleveland meeting with as clean and final a TD-CSTS as possible.

Thanks.

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

This message and any attachments are intended for the use of the addressee or addressees only.

The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its

content is not permitted.

If you received this message in error, please notify the sender and delete it from your system.

Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

________________________________

Spam<https://filter.gst.com/canit/b.php?i=01Qoya1xI&m=5ae916aa2610&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01Qoya1xI&m=5ae916aa2610&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01Qoya1xI&m=5ae916aa2610&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20160301/1c626ac2/attachment.html>