[Css-csts] RE: Buffered Data Processing Procedure

[John Pietras]

Martin,
Here's the completion of my responses.

Best regards,
John

From: Martin Götzelmann [mailto:martin.goetzelmann at vega.de]
Sent: Tuesday, January 29, 2013 4:00 PM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: RE: Buffered Data Processing Procedure

Dear John,
.
.
.


I would also be interested in your opinion regarding the  presentation of derived procedures in general as reflected by the questions I have inserted as comments into the BDPP.

[JP]


1.       Regarding sending individual P-D invocations in addition to Transfer Buffers -  it seems to me that there are two possible reasons for wanting to retain the "un-Transfer Buffered" direct transfer of P-D invocations: (1) the possible need to do so to be formally derived from the (simple ) DP procedure (as mentioned in your comment) and/or (2) to accommodate the possibility that some applications and/or implementations may be able to handle the maximum possible load without the overhead of wrapping the D-P invocations in Transfer Buffers.

Regarding the first reason, I don't have a strong opinion about whether it is necessary to support the transfer of stand-alone P-D invocations to meet the definition of derived. I think that it would be nice, but at the same time I think that procedure specification itself would need to be modified to ensure the proper behavior in this case - currently the Transfer and Queuing of PROCESS-DATA Invocations behavior is specified only  in terms of Transfer Buffers. And even if these changes are made, is there any likelihood that a user will choose to send stand-alone P-D invocations - that is, is there any validity behind reason #2?

If the WG decides to retain the ability to have this procedure transfer stand-alone P-D invocations, I would recommend that it not be referred to as an "optional" capability (see 1.1.2.2, third paragraph). "Optional" is routinely (although I haven't checked enough to be able to say exclusively) used to indicate something that an implementation may or may not support, and I don't think that is what is meant in 1.1.2.2. I think that the correct flavor is "The Service User may send either Transfer Buffers or individual P-D invocations ..."

Finally, thinking more about the nature of the derivation of BDP from DP and the questions (discussed elsewhere) regarding the normative specification of flow control in the underlying comm service, I'm now wondering whether it is possible for the simple DP procedure to encounter a situation where the 'process data unit' action is not possible when 'data unit ready' occurs, and if so, what happens? Maybe this is just a semantic issue, and maybe it is tied up with the question of whether the "processing function" is part of the procedure or part of the production. I guess one way to get around this concern is to essentially define 'process data unit' to always occur, and if the processing function is not ready to actually process the data unit the processing function will have to do something with it (where the definition of what that something is can be deferred to the service/derived procedure). That in turn could lead to other extensions in derived procedures, e.g., an extension value for the NOTIFY invocation's data-processing-status parameter to indicate that the data unit has been discarded because the processing function couldn't deal with it at the time that it became available on the queue.


2.       Regarding behavior that is completely inherited: I prefer either the way you have it now or your alternative (b). I think the reader could use the reminder that there is derived behavior and not just assume that he'll automatically fill in all the blanks.


3.        Regarding behavior that is an extension to inherited behavior, I prefer option (b) - although technically equivalent, I think identify that there is inherited behavior up front better prepares the reader  to read the modifications in the context of that base behavior.


4.       Regarding 'transfer buffer too big' diagnostic: it's interesting that BDD doesn't address too-big PDUs, but that's somewhat understandable since the BDD transfer buffers are generated by the Provider and therefore more often assumed (perhaps incorrectly) to be right - the diagnostics have a bias toward catching User errors.

However, I think that the more appropriate SLE comparison is to the maximum-cltu-length managed parameter of FCLTU. If a CLTU exceeds that value, the CLTU-TRANSFER-DATA operation fails with diagnostic 'CLTU error', but the association is not aborted. Did the WG discuss in Cleveland how a too-big CLTU is handled, and if so why did it conclude that too many P-D invocations in a transfer buffer is a peer-abortable situation whereas a too-big CLTU is merely rejected?


5.       I agree with the approach of citing the parent procedure in the required operations table even if the operation has been inherited unchanged from a non-immediate ancestor.

Finally, as you have not come back to the points in the Simple DPP for which I had included comments in version 10, can I assume that these are OK for you?

[JP] Yes

Kind Regards, Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130206/5070fbc9/attachment.htm