[Css-csts] Revised Forward Procedures for integration into the
Framework
John Pietras
john.pietras at gst.com
Tue Jun 18 16:41:02 EDT 2013
Wolfgang,
I will admit that arguing for procedures that will run over unreliable networks is not consistent with a basic assumption being made for all CSTSes, and that if we use that new criterion in the case of the forward procedures we should logically re-evaluate all of the procedures against it.
But putting aside the running-over-unreliable-networks consideration, the "+1 else PEER-ABORT" approach is too unforgiving (in NASA's view) for a procedure that is not supposed to enforce sequencing in the first place. Based on email discussions within NASA prior to my previous comments on this topic, NASA would prefer that the BDPP be robust with respect to sequence numbering, even if that might allow the user to do something that lowers the usefulness of the feedback from the service.
One possible arrangement might be:
- In the (simple) DPP, carry the data-sequence-number and explain how its values are reported back in the notifications, but put *no* enforcement requirements on the DPP. The DPP specification would simply state that users _should_ put in unique sequence counter values in order eliminate ambiguity in the notifications. The DPP specification could also restate that derived procedures could add behavior related to the sequence counter.
- In the Sequence-Controlled DPP, the "+1 or reject" behavior can be added.
- In the BDDP, a notification can be optionally sent (controlled by configuration parameter) if the sent sequence number in a PROCESS-DATA invocation is not 1+ the value of the previous P-D invocation, but an out-of-sequence invocation neither is rejected nor does it trigger a PEER-ABORT.
Of course we will talk about this issue more at tomorrow's CSTSWG telecon, but I wanted to state a proposed alternative a bit more succinctly than I did in my previous comments.
Best regards,
John
-----Original Message-----
From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
Sent: Friday, June 14, 2013 5:26 AM
To: John Pietras; Sylvain Gully
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
Subject: RE: [Css-csts] Revised Forward Procedures for integration into the Framework
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<mailto:john.pietras at gst.com>> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Wolfgang.Hell at esa.int<mailto:Wolfgang.Hell at esa.int>" <Wolfgang.Hell at esa.int<mailto:Wolfgang.Hell at esa.int>> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>" <css-csts at mailman.ccsds.org<mailto: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<mailto:|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<mailto: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.
--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------
NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Teach CanIt if this mail (ID 01JM9tHwC) is spam:
Spam: https://filter.gst.com/canit/b.php?i=01JM9tHwC&m=50838cd6b168&c=s
Not spam: https://filter.gst.com/canit/b.php?i=01JM9tHwC&m=50838cd6b168&c=n
Forget vote: https://filter.gst.com/canit/b.php?i=01JM9tHwC&m=50838cd6b168&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130618/7cd45686/attachment-0001.html
More information about the Css-csts
mailing list