[Css-csts] Revised Forward Procedures for integration into the
Framework
Wolfgang.Hell at esa.int
Wolfgang.Hell at esa.int
Fri Jun 14 05:26:11 EDT 2013
John and Sylvain,
As announced, this is my response to the questions and concerns you raised
regarding the changed specification of the sequence-counter in the BDPP.
Your understanding of why the change was made is exactly right. I can see
from your discussion that you have considered exactly the same options as we
did, only your final conclusion is different.
What you suggest is certainly feasible. However, to me it looks somewhat
inconsistent. On the one hand you agree that the Framework as is mandates a
reliable underlying communications service. If we stick to that, then there
is no reason not to accept the modified +1 increment requirement of the
sequence-counter value in BDPP. If we are serious about considering Framework
based services over unreliable networks, then we should lift the assumptions
in section 1.3.1 of the Framework. But then we need to look at the complete
picture. Running over an unreliable network is likely to affect also other
procedures. What is the point in considering this case for the forward
procedures only? This is just my personal view.
I look forward to discussing this issue during the next telecon and will be
glad to update the forward procedures as per the outcome of the discussion.
For now, I have not applied any changes with respect to this point.
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