[Css-csts] Issue with using the Buffered Data Delivery Procedure for Real-time Radiometric Data

[John Pietras]

Yves,

Thank you for your comments. I agree with you that some variation of
either option 2 or option 4 are the most viable. 

 

I don't think that your proposed option 5 would work, at least not
exactly as you have stated it (below). The Header data is supposed to
occur once for every TDM, and so it should not be repeated in every
transfer buffer, because to do so would essentially turn each transfer
buffer into its own TDM, that's okay from a formal TDM definition
viewpoint, as long as it's accompanied by the Metadata (which is also
part of option 5). But repeating the Metadata in each transfer buffer
will likely outweigh the actual Data content of the transfer buffer
(NOTE that although we are using the Buffered Data Delivery Procedure
(BFFP), I think that in real-time mode it is very likely that the
latency limit will predominate - that is, tracking measurements from
successive sampling periods will not be allowed to accumulate in a large
transfer buffer.) Since I have been working from the perspective that we
are trying to minimize the redundant information carried by the service,
I think that this makes option 5 not viable.

 

Regarding your variation of option 2, I believe that I have been
thinking on similar lines. That is, the TRANSFER-DATA invocation is
normally used to carry all TDM Header, Metadata, and Data segment
contents. If there is a data discard situation, the NOTIFY invocation
carrying the discarded data notification would be extended to also carry
the Metadata that is in effect at the time the new segment is sent (we
could consider making this process even more "intelligent" and only
updating the Metadata if anything has changed since the last successful
transfer buffer, but for now I think the algorithm is simpler to just
update the Metadata every time a transfer buffer is discarded).

 

For the complete delivery mode, all TDM content is carried purely in
TRANSFER-DATA invocations, which is nice and clean.

 

This approach still has the derived Radiometric BDDP doing more than the
basic BDDP, but I think it's a relatively reasonable extension of the
BDDP. 

 

I'm less happy with option 4 -  I don't that it's very fair to advertise
that the service is built on a reliable, sequence-preserving underlying
communication service, but to then give the user application two data
flows that must be re-ordered and say "here, you sort it out".

 

Unless anyone has serious objections, I'd like to proceed further with
option 2, as modified by this discussion, as the basis for the first
draft of the RRD-CSTS White Book. I think that it will be a valuable
exercise in helping us understand what it means to derive procedures
from existing ones, even if we ultimately decide to do something else
(like option 4). We can still discuss both options 2 and 4 in the joint
meeting with the NavWG, in case they can provide additional insight from
their perspective as potential users of the service. My guess is that,
from the user perspective of the service, option 2 would be preferable
to option 4, and that they (the NavWG members) won't care which approach
requires more or less derivation of base toolkit procedures. 

 

Best regards,

John

 

 

________________________________

From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Monday, February 25, 2008 2:32 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] Issue with using the Buffered Data Delivery
Procedure for Real-time Radiometric Data

 


Dear John, 
Thank you for sharing your concern. 

I read the various proposals and please find below my thinking. 

1. This first option implies a complete new procedure that would have
the knowledge of what can be discarded and what cannot be discarded. I
am not very enthusiastic with that option. So, I agree with you. 

2. If I understand correctly, the header and meta-data would be
transferred with the  NOTIFY operation. In case data would be discarded,
the "data discarded" notification would be extended to carry the missing
header and meta-data. 
I see the following issue. How will the service know what data was
discarded and what data need to be repeated in the "data discarded"
notification? 
The disadvantage of that option is that we (sort-of) misuse the
notification for carrying data. 
An alternative would be to transfer the header and meta-data using the
TRANSFER-DATA operation and only use the "data discarded" notification
to complete the missing data. 

3. I don't like this approach either. 

4. The use of two different instances is also quite tempting but I would
propose a first BFFD instance for delivering the data and a second
instance of the BFFD for delivering the header and meta-data. The second
instance would be used with the complete mode ensuring that no data is
discarded. As you state, each message is time tagged so that the user
can reconstruct the correct sequence. 
The advantage of that option is that data would come cleanly from two
procedure instances. The disadvantage is that the user must re-sequence
the data. 

In my view only option 2 and 4 viable and should be studied. Could you
please let me know your opinion regarding the option 2 alternative I
proposed. Do you consider the option 4 not viable? 

Another option (5) would to systematically add at the beginning of the
transfer buffer the header and the meta-data so that even if a buffer is
discarded the information is transferred with the next transfer buffer.
I do not have the TDM format with me and I am not sure if that option
would be acceptable. What do you think? 

Best regards 

Yves




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