[Css-csts] tracking data recording buffer retention issues

Tue Mar 1 10:10:49 UTC 2016

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

From:   "John Pietras" <john.pietras at gst.com>
To:     "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<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

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
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20160301/9be29e87/attachment.html>