TR : [Css-csts] Issues regarding Cyclic and Unbuffered Data DeliveryProcedures - Update

Fri Jul 13 08:32:20 EDT 2007

Members of the CSTS WG,
Neither me, nor Thomas will be available for the next teleconference on the 31/07, so I send to you our answers about the comments made by John last week.
Best regards.
François

A. List-of-parameter member validity as a condition for positive result of the START operation

In the Behavior section, paragraph 2.2.3 states "If at least one of the parameters of the list is unknown then the START operation shall return a negative result and the diagnostic shall contain the list of unknown parameters." I remember we had long a discussion on that point and unless I made a misunderstanding we have decided that the procedure behavior is consistent with this 2.2.3 paragraph. However it's true that in the paragraph 3.1.6.1 ( b)Extended diagnostic), 'all parameter names undefined' should be replaced by 'list of unknown parameters :'. In addition, I think that the use of the words "unknown" and "undefined" is not yet completely clear in the procedures : So far I have understood that, when a parameter is not mentioned in the list-of-parameters, it is called an "unknown parameter" and it has an "unknown value" as qualifier. When a parameter is in the list but its value for any reason is not yet available this parameter has an "undefined value". Do you agree on that ? If you do, we have to update the procedures because some sentences are not consistent with this definition.

B. Number of parameter values reported in a single TRANSFER-DATA invocation

action item#07-0107 states "The Cyclic Data Delivery procedure delivers a sequence of parameters as part of the TRANSFER-DATA. The structure should be identical to the list delivered with the GET. Careful analysis is required as the TRANSFER-DATA cannot contain this definition and it may be that list is to be defined in the Cyclic Data delivery procedure." Do you agree that we should replace the content of the paragraph 3.3.2.2 (data) in the Cyclic Data Delivery Procedure by  the content of the paragraph 4.13.2.3 List-of-parameters-values for the GET operation in the procedures definition document ?

C. Conflict between cyclic reporting and 'live data' concept in the underlying Unbuffered Data Delivery procedure

In my understanding there is not necessarily a conflict : we can consider that the provider doesn't wait before data delivery but waits for timer expiration then parameter values are acquired and transmitted "as soon as possible after their production". "as soon as possible" is not a very precise specification. However in order to avoid too strict interpretations the "as soon as possible after their production" could be reworded for example in the following way : "transmitted in the next tranferring data operation". We think that giving as suggested a timestamp for each parameter monitored would be an important constraint.

D. Ambiguity about data discard policy in the underlying Unbuffered Data Delivery procedure

I suggest we replace the following sentence : "If the underlying communications service generates backpressure because of congestion, the service provider shall discard the data and/or notification." by this one, taken from the Transfer Buffer paragraph in the RAF document : "If new data needs to be inserted into the transfer buffer, but the transfer buffer is full and cannot be passed to the communications service provider due to congestion of the communications service, then the entire transfer buffer is discarded as one unit."

E. Redundant parameters of Unbuffered TRANSFER-DATA and base operation.

I agree, it will be corrected.

F. Various typographical errors and editorial issues in the Cyclic Data Delivery Working Note

a: I think probably there were several internal versions of the working note before it was updated.
b: I agree, it will be corrected.
c: I agree, it will be corrected.

-----Message d'origine-----
De : css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] De la part de John Pietras Envoyé : mardi 10 juillet 2007 21:01 À : css-csts at mailman.ccsds.org Objet : [Css-csts] Issues regarding Cyclic and Unbuffered Data DeliveryProcedures - Update

Members of the CSTSWG --
Last week I sent a message identifying some issues with the latest release of the Cyclic Data Delivery Procedure Working Note (Issue 1, Rev 2, dated 13 June 2007). I have since found an action item from the January meeting that modifies previous comments. Below is a re-issue of the previous comments, with items B and C modified to reflect the action item.

-----
In reviewing the latest Cyclic Data Delivery Procedure Working Note (Issue 1, Rev 2, dated 13 June 2007), I've come across what appear to be several inconsistencies and/or errors. I've tried to go back through the Minutes of Meetings, etc., for previous discussions and decisions, but found none that explained or resolved these issues.

A. List-of-parameter member validity as a condition for positive result of the START operation

In the Behavior section, paragraph 2.2.3 states "If at least one of the parameters of the list is unknown then the START operation shall return a negative result and the diagnostic shall contain the list of unknown parameters."

However, the subsequent definition of the START operation has an extended diagnostic value 'all parameter names undefined' (paragraph 3.1.6.1 (b)) but makes *no* mention of containing a list of unknown parameters.

It is my impression that the intention is to allow the START (and thus the procedure itself) to succeed if *any* of the named parameters in the list-of-parameters is defined. This interpretation is consistent with the way the START operation itself is defined in section 3.1, but counter to the way the behavior of the START operation is defined in 2.2.

The behavior of the TRANSFER-DATA operation as stated in paragraph 2.3.4
- "If the value of a parameter of the 'list-of-parameters' is currently unknown then the returned qualifier value of the parameter shall be 'unknown value'." - can be strictly interpreted as supporting the "positive result only if *all* of the parameters are valid" approach. However, by adding another qualifier value -'unknown parameter'- the "positive result if *any* of the parameters are valid" approach can also be supported.

B. Number of parameter values reported in a single TRANSFER-DATA invocation

As currently defined in section 3.3.2.2, each cyclically-reported parameter from the list-of-parameters is reported in it's own TRANSFER-DATA invocation. However, action item#07-0107 states "The Cyclic Data Delivery procedure delivers a sequence of parameters as part of the TRANSFER-DATA. The structure should be identical to the list delivered with the GET. Careful analysis is required as the TRANSFER-DATA cannot contain this definition and it may be that list is to be defined in the Cyclic Data delivery procedure." The change has yet to be made.

Note - there may be a good reason to have the Cyclic TRANSFER-DATA operation transfer more information than is found in the GET operation - specifically, a timestamp for each monitored parameter. This is discussed in more detail in item, C, below.

C. Conflict between cyclic reporting and 'live data' concept in the underlying Unbuffered Data Delivery procedure

The Cyclic Data Reporting procedure is built around the notion of reporting data periodically. Section 2.3.2 states" The provider shall arm a periodic timer to deliver data periodically at the interval of seconds defined by the value of the parameter 'delivery-cycle'."

However, this procedure is derived from the Unbuffered Data Delivery procedure(the most recent version of which is called "1.7" in the file name but "Issue 1 Rev 5" on the cover page), which states in section 1.2 " The provider transmits live data...  Transmission of 'live data' implies that data units are transmitted as soon as possible after their production."

There is a conflict between stating that the data are delivered both "as soon as possible after their production" and waiting to "deliver data periodically at the interval ... defined." This conflict might seem like a simple issue of phrasing, but taken in conjunction the two statements could be strictly interpreted as requiring that the data that is being
*reported* at time X be *sampled* at time X. In fact, I have been a party to a status reporting system design review process where that exact issue was a point of contention (customer thought he was getting a sample that was only a few milliseconds old, vendor was actually only planning to deliver something that had been sampled sometime since the last (5 second) report was sent), so it is not merely a philosophical exercise.

My understanding is that for many systems, actually sampling the measurands within mere microseconds before the report is generated is not always (or even often) a requirement, and we probably don't want to implicitly build that into our Cyclic Data Delivery procedure. Some derived services, or specific implementations of derived services, may have such split-second requirements, but those can be added for those cases.

I think the simplest way to solve this problem would be to loosen the "as soon as generated" wording in the Unbuffered Data Delivery procedure and find alternate ways to express what is really happening. But there might be other approaches, also.

If we do decide to construct the Cyclic Data Delivery procedure so that it can deliver the collection of measurand values at some time other than when the values were actually sampled, do we need to give each measurement its own timestamp to identify when that measurement was actually made (as opposed to the generation-time of the TRANSFER-DATA invocation that transfers the measurement), or is it sufficient to treat every measurement in a TRANSFER-DATA invocation as though it had been actually sampled at that same time (i.e., the generation-time of the TRANSFER-DATA invocation itself)? Note that if timetagging of individual measurements is used, then the content of the data parameters will be somewhat different from those in the GET operation, and the resolution behind action item #07-0107 will have to be modified (see item B, above).

D. Ambiguity about data discard policy in the underlying Unbuffered Data Delivery procedure

This is really an issue regarding the Unbuffered Data Delivery procedure, but I'll raise it here because it affects (by derivation) the Cyclic Data Delivery procedure.

Section 2.3.3 of the CSTS Unbuffered Data Delivery Procedure states that "If the underlying communications service generates backpressure because of congestion, the service provider shall discard the data and/or notification." The amount of data to be discarded is ambiguous - although the intent is to discard only the data that is available for transmission, it is possible to misinterpret this statement to apply to all data generated after the congestion occurs.

Contrary to its name, I believe that the Unbuffered procedure really does have a transfer buffer (although it is constrained to be only one invocation deep), and that the procedure essentially acts like the Timely mode of the Buffered procedure. If this is a correct interpretation, then if the Timely material from the Buffered procedure specification could be trimmed down to contain only what applies to the Unbuffered procedure it would provide a much clearer definition of what is to be discarded (and when) that the current wording of the procedure.

E. Redundant parameters of Unbuffered TRANSFER-DATA and base operation.

Again, this is really an issue regarding the Unbuffered Data Delivery procedure.

The base TRANSFER-DATA operation is defined in the February draft of the CSTS Procedures Definition as having generation-time and sequence-counter parameters. However, the TRANSFER-DATA operation in the Unbuffered Data Delivery procedure has generation-time and sequence-counter extension parameters, which are redundant with those of the base operation.

F. Various typographical errors and editorial issues in the Cyclic Data Delivery Working Note

a. The file name is CSTS Cyclic Data Delivery Procedure 1.4, but the cover sheet is "SLE Transfer Service Cyclic Data Delivery Procedure Working Note Issue 1, Rev 2". The cover sheet name should change to CSTS (Note - this is a common issue across multiple working notes). What, if anything, is the relationship between the numbering conventions used in the file name (e.g.,
1.4) and on the cover sheets? (Note - this is a common issue across multiple working notes)

b. The page header on each page is "CSTS PROCEDURE: STATUS REPORT"

c. The delivery-cycle (section 3.1.3), list-of-parameters (3.1.4), extension-parameters (3.1.5), and diagnostic (3.1.6) sections should be under section 3.1.2 (Invocation, Return, and Parameters), not peer with it. Also, the parameter names should not be enclosed by single quotes - single quotes are used for parameter values.

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts