[Css-csts] Issues with Buffered Data Delivery state table

Fri Aug 14 16:03:00 EDT 2009

CSTSWG colleagues - 

I have been looking again at the state table for the BDD procedure in CSTSFW R-0.19, and I have come across a number of issues:

1.	The (pseudo) event 'any conformant event' entry in table 4-11 references section 4.5.3.2, which lists the notification types inherited from the base NOTIFY operation as well as the BDD-specific extensions. One of these notification-types is 'end of data'. One could infer that 'end of data' qualifies as 'any conformant event', and therefore its occurrence would be handled as specified in row 7 of the state. However, 'end of data' has its own row (6). Clearly, the intent is that row 6 applies, but that might not be understood by the naïve implementer.

2.	Similarly, the notification types in 4.5.3.1 list 'data discarded due to excess backlog'. Again, one could infer that the discarding of the data is itself an event that needs to be notified, but if 'data discarded due to excess backlog' is substituted for 'any conformant event' in the active column for row 7, the result is not what is desired.

These two examples point up a flaw in defining events in terms of the notifications that are emitted upon the occurrence of those events - it can result in self-referencing loops in the logic. The problem can be partially solved by removing the reference to 4.5.3.2 from the 'any conformant event' entry in table 4-11. However, that leaves only paragraph 4.5.2.3.7 to "define" 'any conformant event', and 4.5.2.3.7 really only defines synchronous insertion of notifications. It does not give a clue as to what a "conformant" event might be. As I recall, what we really meant "any conformant event" to mean was any event that a derived procedure might add. I propose that:

a)     The event 'any conformant event' be renamed 'derived procedure event';

b)     A new paragraph 4.5.2.3.9 be inserted between 4.5.2.3.8 and the current 4.5.2.3.9: 
"A derived procedure may define its own procedure-specific events. The Service Provider such notify the User of every procedure-specific event via a NOTIFY invocation with a notification-type that is unique to that event. 
NOTE - The specification of the derived procedure explicitly identifies each procedure-specific event that is to be treated as a derived procedure event, and identify the notification-type that is to be used when that event occurs."

c)     The 'derived procedure event' entry in table 4-11 reference the (new) paragraph 4.5.2.3.9, rather than 4.5.2.3.7.

d)     Put requirements in the Guidelines that mandate that if new notification-types are added to a NOTIFY operation, then the Behavior section for the procedure explicitly identify the events that qualify as 'derived procedure event'.

3.	In the 'production status change' row of table 4-11, the Event column entry concludes with "; 'any other event'".  There is no 'any other event' mentioned anywhere in the specification. This seems to be an earlier version of 'any conformant event', but even so it should not be grouped with production status change. The phrase should be deleted.
4.	'production status change' and 'derived procedure event' ('any conformant event') follow the convention for event names (single quotation marks), but they are actually event group names, each representing a set of actual events and notification types. It would be easier to interpret the state table if there were a separate convention for such group names. For example, <production status change> and <derived procedure event>. These terms could then appear in the Event Description References table with identification of the actual events that they represent. 

5.	The 'end of data' entry in table 4-11 references paragraph 4.5.2.3.9.4. Bullet (d) of 4.5.2.3.9.4 identifies one condition that qualifies as an indication of end of data ("a TransferDataInvocation is retrieved with a generation time that is later than the stop generation time in the START invocation"). Bullet (c) of 4.5.2.3.9.4 implies that there might be other such conditions ("a NotifyInvocation 'end of data' was inserted into the transfer buffer"), but none are defined anywhere in the BDD specification, leaving the implementer wondering if he's overlooked something. The 'end of data' entry in table 4-11 also references paragraph 4.5.3.2.1.1.1, where bullet (c) defines 'end of data' as "the Service Provider has no more data to send. This notification is non-discardable". This is a vague statement; what condition(s), other than the one identified in 4.5.2.3.9.4 (d), might constitute there being no more data to send? That is, how does a Service Provider know that there's no more data? 

	It may be that what constitutes end of data is specific to the derived procedure. If that's so, then there should be a requirement on the derived procedure specification to define what "end of data" means in the context of that derived procedure.

6.	In the third paragraph of 4.5.1.2.2.2 (Recorded Buffer), bullet (d) states: "Upon the occurrence of any of several events that cause a change to or disruption of the data being provided, the Service Provider stores a synchronous notification of the event in the buffer. The notification is a NOTIFY invocation. The notification is stored into the buffer after the last data acquired before the event and before the first data acquired following the event.  The events notified and associated information that are stored shall be as defined in 4.5.3.2." A strict interpretation of this statement is that all event notifications specified in 5.5.3.2 are to be stored in the recorded buffer. This cannot be true, because the recorded buffer is shared by all service instances (bullet (b)) and some of the notifications are service instance specific. I.e., when data is discarded by a real-time mode service instance, the resulting notification must be sent to only the user of that service instance (putting it in the recorded buffer would cause it to be sent via all instances). Likewise, an 'end of data' notification triggered by the retrieval of a TransferDataInvocation with a generation time that is outside the bounds of the service instance applies only to that service instance and must not be put in the recorded buffer.

The situation is complicated by the fact that the state table is for the procedure (and thus a particular service instance), but some of the actions that are attributed to those procedures are actually performed by the service production that is common to all services instances of that type. This leads to confusion (for me, anyway) in trying to interpret the relationship between when the real events occur and when they are notified. For example, take the case of a 'production status change' event. By my reading of the state table, row 7 tells me that the service instance generates the notification at the time that the event itself actually occurs. However, consider the case of a complete-mode service instance that's lagging behind the real-time data generation rate a bit. I *think* that what is desired is that the notification be generated in relative timing with respect to the data being sent, but I don't think that is actually stated in the specification.

I don't have a good solution for the overall problem of the intermixing of the procedure state table wit the production processing, but I have a suggestion for clearing some of the confusion about what notifications get put in the recorded buffer and which ones are sent only by the service instances and fix the immediate problem with paragraph of 4.5.1.2.2.2 (Recorded Buffer), bullet (d). In the definition of the notification-type extension values in section 4.5.3.2.1.1.1, add information that specifies whether the notification is to be stored in the recorded buffer or not. That is:

- for item (a) (which deals with the standard production status notifications that affect all service instances tied to that production process), add the sentence "These notifications shall be stored in the recorded buffer."; and

- for item (b) ('data discarded ...'), add the sentences "Notifications for data discarded due to recorded buffer overflow shall be stored in the recorded buffer.;

7.	 What is the difference between the actions 'sync notify 'xxx'' and. 'insert the notification into the transfer buffer'? The cited references for each don't help understand them. 'insert the notification into the transfer buffer' references 4.5.2.3.9.3, which is about the transfer buffer size. 'insert the notification into the transfer buffer' also references 4.5.2.3.9.4 c), which states "a NotifyInvocation 'end of data' was inserted into the transfer buffer" - again, a circular reference.  'sync notify 'xxx'' references paragraph 4.5.2.3.7, which talks about synchronous insertion of notifications in the real-time delivery mode.

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/20090814/aafb4a8a/attachment-0001.html