[Css-csts] Concerns about a "Forward AOS" CSTS

[John Pietras]

CSTSWG colleagues ---

 

Increased attention is being paid to the enhanced FCLTU Orange Book and
the CSTS-based service that will eventually provide the synchronous
frame forward link transfer service that the Orange book addresses
experimentally. I have begun to consider what such a synchronous frame
forward link CSTS (I'll call it the "F-AOS Frame CSTS") would look like,
and I'm very concerned that the Framework, as it now stands, will not
support this service. To state the problem in highest-level terms, the
Framework does not have an operation that can be used to transfer the
frames without imposing Telecommand-related behavior that is
inappropriate for the F-AOS Frame service. As we know, one of the
constraints of the Framework (formerly toolkit) approach is that all
operations in CSTSes must be in the Framework - we cannot create new
service-specific operations. So unless we have at least one operation in
the Framework that can be used for such a service, we won't be able to
create a suitable CSTS.

 

Fortunately, there are at least two operations in the current (0.19)
Framework that could be modified (slightly, I believe) to meet the
purposes of the F-AOS Frame service (and, in addition, make those
operations generally better-suited to broader use in other future
CSTSes). The following paragraphs explain the problem further and
describe the two possible solutions that I have identified.

 

Only one operation (PROCESS-DATA) is defined in the Framework for moving
arbitrary data from User to Provider, and only one procedure (DATA
PROCESSING) is defined for moving arbitrary data from User to Provider.
The problem with both the procedure and the operation is that they
incorporate too much of the Telecommand-related behavior of the FCLTU
SLE service. In developing the Enhanced FCLTU Orange Book, we had to
disable, negate, or modify some of this behavior to make it work for a
synchronous forward link. In particular, we "repurposed" the following
characteristics of the FCLTU service:

1 - Re-interpreted the earliest-radiation-time parameter as a mechanism
for building a transmit buffer to minimize gaps in the transmission (if
so desired by the user);

2 - Re-interpreted the latest-radiation-time parameter as a mechanism
for discarding frames that are "too old", so that minimum latency would
be guaranteed (if at the risk discarding some data);

3 - Redefined the processing associated with the cltu-identification
parameter (i.e., the CLTU sequence counter) such that it no longer
discards a "CLTU" if it does not have the next expected sequence number;
and

4 - Redefined the processing of CLTUs that "expire" (pass their
latest-radiation-time while waiting in the transmit queue) so that the
service does NOT block (i.e., require a STOP and START), but rather just
discards the expired CLTU and continues to process the CLTUs that
follow.

 

If I could have started with a clean-slate SLE service for a forward
synchronous frame service, I would have used a queue-depth-based
mechanism for building a queue in the first place and keeping it from
getting too big (analogous to the Buffered Data Delivery service) rather
than using the earliest and latest radiation times. And of course I
would not have the service block when a frame expires. Ideally, this is
what we should be able to do with the CSTS framework operations (and
possibly procedures) to create the F-AOS Frame CSTS.

 

The problem lies in the fact that the undesirable behavior is inherent
in the PROCESS-DATA operation, which is currently the only operation
defined for transferring "data" from User to Provider. There are
probably a number of ways to fix this, but two that occur to me are:

1 - Simplify and generalize the PROCESS-DATA operation, and add the
"telecommand-specific" behavior and parameters via the DATA PROCESSING
procedure, i.e.:

a)     move some of the parameters and behavior currently associated
with the base PROCESS-DATA operation into the DATA PROCESSING procedure,
leaving PROCESS-DATA a less-defined operation (in particular, I'd remove
all parameters from the base PROCESS-DATA operation except
data-sequence-counter and data); and 

b)     create a service-specific procedure for the F-AOS Frame service
that uses the now-simpler PROCESS-DATA operation to do what we need and
not have to undo undesirable behavior from the DATA PROCESSING
procedure.

2 - Redefine TRANSFER-DATA so that is can (once again, as was the case
for the SLE FCLTU and FSP services) go from User to Provider as well as
from Provider to User. Then a service-specific procedure could be built
around a user-to-provider TRANSFER-DATA operation for the F-AOS Frame
service.

 

Note that I am not suggesting that we include a standard procedure in
the Framework that would be tuned to the F-AOS Frame service case.
Rather, I merely want to have a data-bearing operation in the Framework
that can flow from User to Provider that is general enough that it can
be used to create a service-specific procedure for the F-AOS Frame
service. 

 

I realize that this would be a very late change to the Framework, which
is why I'm suggesting approaches that I think will have minimal effect
on the Framework specification. I hope that we can discuss this via
email over the next few weeks, and I propose that it be a topic of
discussion on the telecon in two weeks. 

 

Best regards,

John

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090609/1da85e12/attachment.html