[Css-csts] Revised Forward Procedures for integration into the Framework

[John Pietras]

Wolfgang and CSTSWG colleagues ---

I have reviewed the latest versions (V13) of the forward Procedures. With one exception, my comments below are organized sequentially from the (simple) Data Processing Procedures (DPP) to Buffered DPP (BDPP) to Sequence-Controlled DPP (SCDPP). As usual, some of my comments may address concerns that have already been addressed in a CSTSWG meeting, and if so I apologize for re-raising settled matters. 

My one comment that is "out of sequence" has to do with the decision made between versions 12 and 13 to require that the data-sequence-counter must increase by 1 and causes a PEER-ABORT if it does not. This is not in keeping with the concept of non-sequence-controlled DPPs, of which the Framework BDPP is a (the) prime example. The original driver for allowing alternatives to the old DPP (which has now essentially become the SCDPP) was to loosen the tight controls on what was deemed acceptable for transmission across the forward link (with the understanding that some higher-layer protocols and/or application processes would provide the necessary ultimate protection). 

By my understanding, the desired behavior at the simple DPP level is really just that the P-D invocations be uniquely identified:  the strict increment-by-1 requirement is only necessary for the SCDPP. I can see by the previous email exchanges that the struggle to define how these counter values can be ensured to be unique has caused a lot of re-definition which finally led to the simplified increment-by-1 approach. 

It is true that the increment-by-1 requirement does not actually limit the behavior of DPPs when the underlying communication service guarantees complete and in-sequence delivery (which is currently required by the CSTS SFW). However, at various times the possibility has been raised of allowing (n the future) some CSTSes to run over "unreliable" networks. The use case that was used to justify what has become the BDPP - maximization of frame (CADU) transfer even if frames are missing - would be one such candidate for running over an unreliable network connection. However, under the V13 definitions,  having a frame dropped by the underlying network would cause the service to PEER-ABORT, which is exactly the behavior that motivated many of the changes in the Enhanced FCLTU service.

I have discussed this situation with several NASA colleagues (Tim Ray, Tom Wickline, Erik Barkley, Peter Shames and Ed Greenberg) and the consensus is that we would prefer that the BDPP (and therefore the simple DPP from which it is derived) *not* require strict enforcement of the increment-by-1/PEER-ABORT approach in all cases. Indeed, for NASA's needs, it is not even necessary that the BDPP procedure enforce uniqueness of the sequence numbers. In the most basic form it would be acceptable to NASA to have the specification include a warning to the users that they *should* put unique values in the sequence counters to avoid ambiguity in the notifications. 

NASA is  not necessarily opposed to the existence of some form of BDPP that enforces a strict by-1 incrementing, but we would like there to be some form that does *not* enforce it (and we would propose that the future Forward Frames CSTS use the less-strict version). Two possible ways to do this, of course, are (a) by use of derived procedures or (b) as options within a single procedure. In our discussions, three levels behavior were identified:
1.	Ignore - The values of the data-sequence-counter have no effect on the behavior of the DPP. The DPP will reflect whatever values that the user puts in in the parameters that are reported via the NOTIFY operation.
2.	Notify - Add an event 'sequence discontinuity', to be reported by the DPP whenever the data-sequence-counter is not 1+ the value of the immediately-preceding P-D invocation. The behavior of the DPP is otherwise not affected.
3.	Enforce - Have the DPP enforce the strict incrementing of the counter by PEER-ABORTing is there is a discontinuity on the sequence counter values. 

To keep things simplest and allow the greatest extensibility, the DPP should roll back to a version that just ignores the counter value (other than to use its value when generating the NOTIFY invocations). Derived procedures (BDPP, SCDPP, and procedures that are derived from them) could then modify the behavior as appropriate. This rollback would solve a problem in the V13 SCDPP, which specifies that out-of-sequence P-D Invocations be merely rejected, in contrast to the current requirement of the parent DPP that a PEER-ABORT be triggered (see comment C.1, below).

We hope that the CSTSWG will consider these points.

Now back to the rest of the comments:
NOTE - in the following comments, the section numbers are those found in the documents. That is, they all begin at section 1. (If there are future draft releases of the Forward procedures, might I suggest that they be put into a single document? That way the sections will be uniquely identified, at least with respect to the Forward Procedures.)

A. (SIMPLE) DATA PROCESSING PROCEDURE
1.	Section 2.1.3.2.2: The requirement " Each PROCESS-DATA invocation shall include a sequence number" is redundant with the definition of the PROCESS-DATA invocation as defined in COMMON OPERATIONS. This requirement under the DPP should be deleted.


B. BUFFERED DATA PROCESSING PROCEDURE
1.	Section 1.1.2.1 (Purpose), last paragraph: This paragraph doesn't really address the purpose of the procedure. Also, is the list of ways that transfer mode is selected intended to be exhaustive or merely representative? I suggest dropping this paragraph in section 1.1.2.1, and making any statements regarding  how the mode is to be specified in section 1.1.4.2.2.
2.	Section 1.1.2.2 (Concepts), first paragraph: I think that there is a typographical error in "by the Data Processing procedure in thus making the procedure implementable". I *think* what the paragraph is trying to say is " The Buffered Data Processing procedure extends the Data Processing procedure (see <REF>) and in particular provides specifications for the handling of Input Queue overflow conditions that are left unspecified by the Data Processing procedure. The specification of this behavior makes the Buffered Data Processing procedure implementable."
3.	1.1.4.2.1 (Transfer Buffer): if the User submits only P-D invocations (that is, no buffer is used), is it necessary to specify a Transfer Buffer size? 
4.	1.1.4.2.1.2: "Transfer Buffer size" sounds like a configuration parameter, and as such should use the convention for parameter names (e.g., transfer-buffer-size in Courier font).
5.	1.1.4.2.1.2: In order to increase readability of the requirement, commas should be placed between "size" and "expressed" and between "Buffer" and "shall".
6.	1.1.4.2.1.5: The second paragraph (When receiving an individual un-buffered ..." should be given its own paragraph number.
7.	1.1.4.2.2.1, NOTE 2: The latency timer initial value is defined by the processing-latency-limit parameter. Suggest making this NOTE more-direct by replacing "the latency timer initial value" to "the value of the processing-latency-limit parameter".
8.	1.1.4.2.2.3 states "The size of the Input Queue for incoming PROCESS-DATA operations shall be defined by the service using this procedure ..." , but there is no requirement specifying the *units* of the Input Queue. In order for it to be used consistently with the Transfer Buffer, it must be defined in the same units - that is, a number of P-D invocations.
9.	1.1.4.2.2.4: "maximum" in "maximum Transfer Buffer size" is redundant, since Transfer Buffer size (transfer-buffer-size) is defined as the maximum possible value.
10.	1.1.4.2.2.4, NOTEs: Is this behavior inherent in the procedures themselves, in the abstract requirements on the underlying comm service, or of the TCP-based ISP-1? I think that this is driven by the constraints/behavior of ISP-1. Should these NOTEs make that point? (I think we've had a discussion on this before.)
11.	1.1.4.2.2.4, NOTE 3: The NOTE discusses multiple instances of BDPP operated in complete mode, but the effects are more global - any other procedure that is part of a service that uses the BDPP will be subject to having its messages in the User-to-Provider direction blocked if/when the BDPP instance stops reading from the comm service. The NOTE should be generalized to addressed this larger issue.
12.	1.1.4.2.2.12, NOTE: I believe that the "Processing of Data Units" is really intended to be the header of a new section (1.1.4.3?) If this is true, then the following paragraph (currently 1.1.4.2.2.13) should be 1.1.4.3.1.


C.  SEQUENCE-CONTROLLED DPP
1.	1.1.2.2, third paragraph, and 1.1.4.2.3: These section describe/require a behavior in which a P-D invocation with an out-of-sequence value in the data-sequence-counter parameter results in a rejection of the invocation. However, the SCDPP is derived from the DPP. Version 13 of which mandates that such a sequencing error result in a PEER-ABORT. NOTE that if the recommendation proposed above is adopted, the DPP would leave the behavior undefined so that the SCDPP could define it as it currently is (reject, not PEER-ABORT).
2.	1.1.5.2.1, Table 1-3: The table might be misinterpreted as implying that the Standard Operation Header invocation parameters and the data-sequence-counter invocation parameter are also extension parameters. Suggest putting "See Note" after the "M" in the invocation column for the Standard Operation Header and the data-sequence-counter, and follow the table with the following NOTE: "The parameters of the Standard Operation Header invocation and the data-sequence-counter invocation parameter are as specified for the Common PROCESS-DATA operation (<ref>) and are not extension parameters. They are shown in table 3-1 because they are extension parameters of the Return".


Best regards,
John