[Css-csts] Re: comments on the strawman F-Frame service spec

[Shames, Peter M (313B)]

We should get the DSN, SN, NEN, and JSC MOD guys into this discussion.  Can you two agree on a minor clean-up and then broaden it to include the rest of that NASA crew?  I can provide, I think, some non-Standards team names that we can hopefully draw into the discussion.

Peter



On 6/29/10 11:02 AM, "John Pietras" <john.pietras at gst.com> wrote:

Ed,
Thanks for the comments. See below ---

-----Original Message-----
From: Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov]
Sent: Monday, June 28, 2010 7:43 PM
To: John Pietras
Cc: Shames, Peter M (313B)
Subject: <no subject>

John,  I have a different view for the f-frame service that I will not
discuss here.  But there are two items in your draft spec that I would like
to comment upon.

1) It might be important to designate one service instance as prime so that
that instant ond only that instant could issue Throw Events.  Note that
Service Management could be an authorized user to send configuration
commands/Throw Events without it sending data but given the highest
priority.

Funny you should mention this. I had thought about doing that, and assumed that the F-Frame
service could do it the same way that the FSP service did. But when I looked at the
FSP service spec, I was surprised to find that there is no such restriction applied
(FSP does, however, have a single service instance designated as the invoker of the
FSP-INVOKE-DIRECTIVE to change the state of the COP)> I even sent a message to to
Wolfgang about this earlier this month, asking whether anyone had ever raised the
notion of a single designated instance for throwing events. I heven't heard back from him yet
on this topic.

For the strawman spec, I took the (possibly cop-out) approach that with the forthcoming
Service Control CSTS, there shouldn't need to be a THROW-EVENT in the FCLTU/FSP sense (see
the Note in section 2.1). However, I also stated that a THROW-EVENT could be added.

On thinking about it further, if we do include a THROW-EVENT procedure, it shouldn't
necessarily be restricted to a single service instance, because directives (in CSTS, the
"THROW-EVENT" name is carried over fro SLE, but it's actually "directives" that are
to be "executed")can be local to the service instance. So if we ere to try to restict,
for example, changing the bit rate on the forward link to one "special" user instance
(a good idea), we would probably have to put the limit on the individual directive types and not
on the THROW-EVENT procedure as a whole.

2) I take issue with the following statement in your F-Frame draftS

4-1
C)  Unlike the PROCESS-DATA operation, there is no need for an
earliest-data-process-start-time parameter. The assumption when using a
synchronous forward link is that there is normally something flowing on the
link almost continuously. Allowing one frame/CADU to hold up all subsequent
frames/CADUs for that virtual channel runs counter to this philosophy. If,
for example, a command in a frame is to be executed at a time significantly
later than when it is put into the frame, the concept is that the command
has embedded timing information that prevents the onboard target application
from executing it prematurely;


The earliest radiation time can be used to establish a buffer at the station
that will add some latency but could reduce jitter and outages caused by TCP
drops and fills from the user.

I was being deliberately provocative with that statement. Buildng a queue of frames before releasing them
is important when the service provider does not insert idle frames (because the synchronous link protocol
will fall out of sync otherwise under the conditions that yo mention), but I don't see the
benefit when idle frames are supplied by the provider.

However, on further consideration, the earliest data process start time might (in conjunction
with the latest start time) *might* be used for VCs that have synchronization requirements within a larger
timing cycle, e.g., for VC frames that carry audio. But even here, I'm not sure what the real requirement is:
would it be that each frame be "processed" (i.e., radiated) at a specified time (+/- a few
milliseonds, for example); or that once the first frame of the VC has been processed, every subsequent
frame is radiated at a specified time interval?

With the F-Frame service, we have the opportunity to decide what is really the most desirable mechanism, and not feel that we have to use artifacts of FCLTU if they aren't really the best fit.

John





_______________________________________________________

Peter Shames
Manager - JPL Data Systems Standards Program
InterPlanetary Network Directorate
Jet Propulsion Laboratory, MS 301-490
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-6871

Internet:  Peter.M.Shames at jpl.nasa.gov
________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the first time"

                                                                                             T.S. Eliot



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20100629/b71a923b/attachment-0001.html