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

[John Pietras]

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/9827eac7/attachment.htm