[Css-csts] Revised Forward Procedures for integration into the
Framework
Wolfgang.Hell at esa.int
Wolfgang.Hell at esa.int
Thu Jun 13 09:50:39 EDT 2013
John,
Thank you very much for your comments on the forward procedures. They arrive
just in time as I was about to start integrating them into the Framework. I
shall reply separately to the issue of the sequence counter increment and how
to determine the out-of-sequence condition. In what follows, I respond to the
other comments that you raised. For convenience, I intersperse your comment
with my response.
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.)
WH: As mentioned above, we are about to integrate the forward procedures into
the framework and with that being done, we'll have the unambiguous section
numbers.
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.
WH: Agreed. V14 has been updated accordingly.
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.
WH: I agree that the last paragraph of section 1.1.2.1. should be placed
elsewhere, but we do not move it to 1.1.4.2.2, as we have the formal
requirement addressing this point in 1.1.4.2.2.2. I still think that it is
useful to tell the reader early on that when specifying a service using this
procedure one will have to decide on the mechanism for the selection of the
transfer mode. My inclination is to add the paragrph in question to the
'Concept' section and I have done so in V14 of the document. But I do not
feel particularly strong about this and I am open to other suggestions.
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."
WH: Certainly the paragraph as is does not tell the story as intended. As a
minimum we need to change the text to say: "by the Data Processing procedure
and thus making the procedure implementable". However, the words that you are
proposing express in a more precise and easier to understand way what we
should tell here. Therefore, I have imported your text into V14 of the
document.
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?
WH: To keep things simple, I would think that the Transfer Buffer shall
always be specified by the service using the Buffered Data Processing
procedure. In case the service characteristics require the transfer of
individual data units, the buffer size can be set to 1. I have not made any
changes to the procedure with respect to this comment.
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).
WH: I agree that this will be a configuration parameter. However, in SLE we
applied the fixed width font convention only to parameters being elements of
the SLE operations.Shall we apply it in CSTS also to configuration
parameters. I have not made any changes to the procedure with respect to this
comment.
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".
WH: Agreed and implemented.
6. 1.1.4.2.1.5: The second paragraph (When receiving an individual
un-buffered ..." should be given its own paragraph number.
WH: Agreed and implemented.
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".
WH: Agreed and implemented.
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.
WH: Agreed. I have added that the Input Queue size is expressed in 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.
WH: I see your point. However, I prefer leaving the word maximum in as there
is also the actual Transfer Buffer size when a new Buffer arrives. Using the
word maximum stresses that the limit is addressed here and not the actual
size of the incoming buffer. I have not changed the document with respect to
this comment.
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.)
WH: Although most of the points addressed by the notes are not specific to
ISP-1, but a consequence of the comms characteristic as specified in section
1.3.1 of the framework, I have added a further note that calls up ISP-1.
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.
WH: Agreed. I have extended NOTE 3 pointing out that this will affect any
other procedure using the same connection.
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.
WH: Agreed and updated. However, given that the new section 1.1.4.3 contains
only a single clause, for consistency with the other section the text is not
numbered.
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).
WH: The DPP uses the unconfirmed variant of the PROCESS-DATA operation and as
a consequence, rejecting of the invocation is not possible and therefore the
only possibility for dealing with an out-of-sequence invocation is the
PEER-ABORT. The SCDPP extends the PROCESS-DATA operation by adding a return
and with that in place we can reject an out-of-sequence invocation. Is your
concern that such change is beyond what should be possible by means of
extension? The BDPP needs to deal with the case of an out-of sequence
PROCESS-DATA invocation as well and it does so in exactly the same way as DPP
specifies. If we were to leave this aspect undefined in DPP, we would have to
move that specification to BDPP. For now, I have not introduced any related
change until we have a decision if DPP should be more abstract at the expense
of adding the necessary specification to BDPP.
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".
WH: Agreed and updated accordingly.
Best regards,
Wolfgang
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|John Pietras <john.pietras at gst.com> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Wolfgang.Hell at esa.int" <Wolfgang.Hell at esa.int> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|10/06/2013 19:22 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|RE: [Css-csts] Revised Forward Procedures for integration into the Framework |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|css-csts-bounces at mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the Css-csts
mailing list