<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Dear Margherita,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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 *<b>is</b>* 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The above discussion is about *<b>how</b>* 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I(‘m looking forward to discussing this on Thursday.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Margherita.di.Giulio@esa.int [mailto:Margherita.di.Giulio@esa.int]
<br>
<b>Sent:</b> Tuesday, March 01, 2016 5:11 AM<br>
<b>To:</b> John Pietras<br>
<b>Cc:</b> CCSDS_CSTSWG (css-csts@mailman.ccsds.org); css-csts-bounces@mailman.ccsds.org<br>
<b>Subject:</b> Re: [Css-csts] tracking data recording buffer retention issues<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Dear John,</span>
<o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">We can certainly bring this point to discussion in the next WG Telecon on Thursday.</span>
<o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">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. </span> <br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">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.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">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). </span><o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">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? </span><o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Are the above issues something we should address with the NAV experts?</span>
<o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">We’ll brainstorm about it at the telecom.</span>
<o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Kind regards,<br>
Margherita</span> <o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">--------------------------------------------------------------<br>
</span><b><span style="font-size:7.5pt;font-family:"Verdana","sans-serif";color:#00A1E0">Margherita di Giulio</span></b>
<br>
<span style="font-size:7.5pt;font-family:"Verdana","sans-serif";color:#5F5F5F">Ground Station Back-end Section (HSO-GIB)<br>
</span><br>
<b><span style="font-size:7.5pt;font-family:"Verdana","sans-serif";color:#5F5F5F">European Space Agency ESA/ESOC</span></b><span style="font-size:7.5pt;font-family:"Verdana","sans-serif";color:#5F5F5F"><br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49-6151-902779<br>
e-mail: <a href="mailto:Margherita.di.Giulio@esa.int">Margherita.di.Giulio@esa.int</a></span><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F"><br>
<br>
</span><br>
<br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"John Pietras" <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">"CCSDS_CSTSWG (<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>)" <<a href="mailto:css-csts@mailman.ccsds.org">css-csts@mailman.ccsds.org</a>></span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">29/02/2016 22:14</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">[Css-csts] tracking data recording buffer retention issues</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Sent by: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif""><a href="mailto:css-csts-bounces@mailman.ccsds.org">css-csts-bounces@mailman.ccsds.org</a></span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">CSTSWG colleagues ---</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">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.</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">The current TD-CSTS specifies that the following be established by Service Management:</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">a. the size of the recording buffer;
</span><br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">b. minimum period that the TDM Recording Buffer is required to retain the stored data before it is automatically purged; and</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">c. overflow policy that shall be applied when new tracking data is available to be stored but the TDM Recording Buffer is full</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">The current TD-CSTS goes on to state that the parameter that specifies the size of the recording buffer (</span><span style="font-size:10.0pt;font-family:"Courier New"">tdmRecordingBufferSize)</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">is
queriable.</span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">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
</span><span style="font-family:"Courier New"">recording-buffer-size</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> 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. </span><br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">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.”</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Regarding the recording buffer size, I propose that we continue to have the TD-CSTS specify that
</span><span style="font-size:10.0pt;font-family:"Courier New"">tdmRecordingBufferSize</span><span style="font-size:10.0pt">
</span><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">is not only the parameter by which the buffer size is queried, but also the parameter by which is it configured.</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">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?</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">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.</span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Thanks.</span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span> <br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Best regards,</span>
<br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">John </span><br>
<span style="font-size:10.0pt;font-family:"Calibri","sans-serif""> </span><tt><span style="font-size:10.0pt">_______________________________________________</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>Css-csts mailing list</tt><br>
<tt><a href="mailto:Css-csts@mailman.ccsds.org">Css-csts@mailman.ccsds.org</a></tt><br>
</span><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><span style="font-size:10.0pt">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
</span><o:p></o:p></p>
<pre>This message and any attachments are intended for the use of the addressee or addressees only.<o:p></o:p></pre>
<pre>The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its<o:p></o:p></pre>
<pre>content is not permitted.<o:p></o:p></pre>
<pre>If you received this message in error, please notify the sender and delete it from your system.<o:p></o:p></pre>
<pre>Emails can be altered and their integrity cannot be guaranteed by the sender.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Please consider the environment before printing this email.<o:p></o:p></pre>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:13.5pt;color:black;background:white">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal"><span style="font-size:13.5pt;color:black;background:white"><br>
<a href="https://filter.gst.com/canit/b.php?i=01Qoya1xI&m=5ae916aa2610&c=s" target="canit_note">Spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01Qoya1xI&m=5ae916aa2610&c=n" target="canit_note">Not spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01Qoya1xI&m=5ae916aa2610&c=f" target="canit_note">Forget previous vote</a></span><o:p></o:p></p>
</div>
</div>
</body>
</html>