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

[Barkley, Erik J (317H)]

John, Ed,

Re Throw-event:

It seems to me we need to consider this from more of a general cross-support perspective.  I tend to think that there are some trades that should be considered/executed.

On the one hand we have the notion of each transfer service having a throw event.  If the forward service  is stopped (unplanned) via a throw-event and the spacecraft uses coherent communications (which is common), then, 1 RTLT later as observed at the tracking station, the spacecraft will transition from 2-way to 1-way communications mode which implies an (uplanned) adjustment to all return services based on the return carrier(s) (that were generated in reference to the forward carrier).  So with this model the service user is having to orchestrate all of the throw Events to ensure they have a coherent set of services. Of course there's the small issue of the return transfer services do not have throw events. It also has implications of needing a forward service no matter what to implement control functions even though the service may be return/downlink only.  And I think it also gets to be a bit difficult if there are multiple transfer service instances operating off the same carrier that need to have multiple throw events to keep a collection of transfer services operating in a more or less synchronized fashion.

A different model is to have the CSTS control service as John indicated below.   There is then the further work  required to determine what the vocabulary of the control directives/requests is but in general it seems to me that it should more or less, the extent possible, be expressed in the same vocabulary as that used to indicate a sequence of events.

Another model may be that there is some sort of mix of these types of approaches (which I think John has also hinted at) whereby the throw Events are restricted in scope to directives/requests local to the particular protocol/transfer service instance (for example buffering limits) and a control service that is more global in nature affecting the overall package of services that are currently in operation (for example, switching to a contingency scenario to compensate for lack of main engine ignition).

I would like to suggest that perhaps these options be considered (and there maybe others as well?)  before we decide whether or not throw events should be in the forward frame specification.

-Erik


From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Tuesday, June 29, 2010 11:03 AM
To: Greenberg, Edward (313B)
Cc: Shames, Peter M (313B); css-csts at mailman.ccsds.org
Subject: [Css-csts] RE: comments on the strawman F-Frame service spec


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






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