[Css-dts] Re: Another SLE RAF Question
Wolfgang.Hell@esa.int
Wolfgang.Hell@esa.int
Fri, 15 Aug 2003 11:25:35 +0200
Dear Michael,
Thank you for copying this correspondence to the Transfer Services Working
Group. It would be very helpful if we could establish consensus on this matter
rapidly so that whatever the position might be we include it in the RCF R-2 and
ROCF R-1 books in a form that removes any ambiguity that might be in the RAF
B-1.
My recollection of what was discussed and agreed in CCSDS is as follows:
The online complete delivery mode permits the user to go back to the past within
the boundaries of the given space link session. However, as per the nature of an
online service, any frame can be obtained only once. We tired to make this clear
by using the language that a frame is "removed" from the online frame buffer
when it is put into transfer buffer. As a consequence, if a user were to put
twice the same start and stop times and would allow the telemetry delivery to
run to the 'end of data', on the second attempt this user should receive only
the 'end of data' notification. I believe that that part of the specification is
unambiguous. It is my understanding that the online frame buffer will contain
the frames of the entire pass only as long as the user did effect the delivery
of any frames of that pass. As soon as one frame is passed to the transfer
buffer, this frame and any frames (and notifications) older than that frame are
removed from the online frame buffer.
As specified now, however, the online 'complete' delivery mode actually prevents
complete delivery as soon as a user elects to suspend the telemetry delivery by
invoking the STOP operation. In response to the STOP operation, the transfer
buffer will be flushed and any frames contained in the transfer buffer at that
time can no longer be obtained via the given service instance. At the last
Transfer Services WG meeting we discussed if we should improve the specification
by stating that a telemetry frame shall be removed from the online frame buffer
only once the transfer buffer content is passed to the underlying communications
service. This would avoid that the frames that happen to sit in the transfer
buffer at the moment when the STOP invocation is received or when the
association is lost could be retrieved when the SI becomes active again. We
concluded, however, that it is probably not worth to go for such modification
because:
If a user requires to retrieve telemetry in a piecemeal fashion, this can be
done by specifying appropriate start - stop time intervals rather than invoking
the STOP operation while telemetry is being delivered.
In case of loss of the association, the number of telemetry frames lost due to
the discarding of the transfer buffer content is probably small compared to the
number of frames lost because of the flushing of the buffers used by the
underlying communications service. Such loss could only be avoided by making the
TRANSFER-DATA operation a confirmed operation. The return could then represent
the permission to remove the associated frame from the online frame buffer. WE
discarded that option on the grounds of the associated performance penalty.
The WG therefore took the position that the specification should remain
unchanged but that we should add notes where appropriate pointing out that under
specific conditions the online complete delivery mode does not really provide
for complete delivery under these conditions.
The above discussion of the online frame buffer is purely conceptually. Brian's
observation that the RAF B-1 specifies the behavior of a single service instance
is very valid. I would not expect a real implementation to maintain a separate
online frame buffer per service instance but to implement the specified behavior
by means of SI specific pointers into a shared online frame buffer. The
implementation of a behavior different from what I understand to be specified
now in RAF B-1 is therefore easily possible. But is that desirable? It would
occur to me that then there is no real difference anymore between the online
complete and the offline delivery mode, except that in offline delivery mode
status reporting, most of the notifications are disabled and that in offline
mode one is not restricted to a the telemetry associated with a single pass. It
is conceivable to merge these two delivery modes (in fact, ESA's pre-SLE
implementation of the packet telemetry services did exactly that), but I feel
that this is a rather drastic change coming very late in the game and I fail to
identify a compelling reason for introducing such change.
In conclusion, my personal preference is to retain the present specification and
to limit ourselves to whatever it takes to make the CCSDS Recommendation
unambiguous and to avoid that users may have false expectations. As stated
above, early feedback from the addressees of this note will be very much
appreciated in the interest of stable Red Books.
Best regards,
Wolfgang
|--------+-------------------------------->
| | Michael Stoloff |
| | <Michael.J.Stoloff@jpl|
| | .nasa.gov> |
| | Sent by: |
| | css-dts-admin@mailman.|
| | ccsds.org |
| | |
| | |
| | 15/08/2003 03:26 |
| | |
|--------+-------------------------------->
>---------------------------------------------------------------------------|
| |
| To: Brian Safigan <bsafigan@avtec.com> |
| cc: css-dts@mailman.ccsds.org, "Jeff Boxell" |
| <jeff.boxell@csoconline.com>, Joe Diep <Joe.Diep@jpl.nasa.gov> |
| Subject: [Css-dts] Re: Another SLE RAF Question |
>---------------------------------------------------------------------------|
Brian,
This is not the first time that this particular question has come up. What
follows is just my interpretation of the CCSDS RAF Blue Book Issue 1 and my
understanding of the JPL implementation of RAF service. I have copied the
CCSDS Data Transfer Services working group on this message, and I welcome
any corrections or differing interpretations.
My first comment is to suggest that use of start and stop times with online
delivery mode is probably not a good idea to begin with. In practice, both
JPL and ESA generally set those times to "null" for online delivery
mode. I believe that the start and stop times in the RAF-START operation,
while permitted in online delivery mode, were intended primarily for use
with offline delivery mode, which is how we use them.
However, the RAF Blue Book does permit use of start and stop times with
online delivery mode, so the question you raise ("Should the service return
frames that were previously returned in [a prior] session?") is a valid
one. Various drafts of the specification answered that question
differently, and the RAF Blue Book Issue 1 may even contain some language
that is at least ambiguous and possibly incorrect (another reason not to
use this feature).
This issue was discussed explicitly by the working group during the review
process that preceded publication of the RAF Blue Book. My recollection of
that discussion is that the working group intended that once a frame is
delivered, it is actually removed from the online frame buffer and, thus,
is not available for re-delivery following a re-bind. This is in contrast
to the offline frame buffer, where the contents are intended to be
persistent for some time (days or even weeks).
I am not certain of the behavior of the actual JPL implementation. I
believe that, in the case of complete online delivery mode, the JPL service
provider would re-deliver frames even though they had been delivered in a
previous session.
I hope that this information is of some use to you. As previously noted,
comments, corrections, and other interpretations are welcome.
--Regards,
Michael
At 02:27 PM 8/14/2003 -0400, Brian Safigan wrote:
>Michael,
>
>I thought I asked you this question before, but I can't find the email, so
>sorry if you already answered this.
>
>CSOC and Avtec has a difference in interpretation of the RAF 'Complete
>Online Delivery Mode' implementation. We implemented an online frame
>buffer that stores all of the frames of a pass to a file. When a user
>'Starts' the service in Complete Online Delivery Mode, they specify the
>range of times to return.
>
>The difference in interpretation has to do with what happens if a user
>Stops and Restarts the service with the same range of times to return.
>Should the service return frames that were previously returned in the
>first session?
>
>The specification is not clear on this. CSOC pointed out that...
>
>According to RAF Spec 3.1.8.2.4 "While the RAF service provider is in
>state 3 ('active') and the transfer buffer is not full, the provider shall
>remove RafTransferDataInvocation and RafSyncNotifyInvocation records from
>the online frame buffer and insert them, in the same sequence, into the
>transfer buffer."
>
>The word 'remove' implies that the frame will not be available for future
>sessions. However later in the spec...
>
>3.1.8.2.10 "In the case that the user invokes the RAF-STOP operation or
>the association becomes unbound, the user may, after re-binding if
>necessary, invoke a new RAF-START operation, with a start time in the
>past, to effect delivery of the data buffered in the online frame buffer.
>Any frames with an ERT older than the start time specified in the
>RAF-START operation and any notifications falling into the same interval
>shall be removed from the online buffer."
>
>We interpret this to imply that the frames from the ENTIRE pass should be
>available for retransmission in case the user restarts the service.
>However, I can see how CSOC may be correct. If the frames are in fact
>removed from the buffer, I assume it is only removed for a single service
>instance (since several service instances may be assigned to the same
>physical channel).
>
>Could you please clarify this and tell us how you and ESA interpreted this?
>
>Thanks for your time,
>Brian Safigan
>Avtec Systems
>(703) 219-1861
_______________________________________________
CSS-dts mailing list
CSS-dts@mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/css-dts