[Css-csts] Revised Forward Procedures for integration into the
Framework
Martin Götzelmann
martin.goetzelmann at telespazio-vega.de
Fri May 3 11:12:29 EDT 2013
Dear Wolfgang,
Just a quick response on three points:
Ad (2) –– I still do not understand how you can get a problem for the buffered DPP. In case of buffer overflow the oldest data are discarded which by definition of a queue are at the head of the queue. If data are discarded due to expiry of the latency timer, these are also the oldest data because the latency timer is the same for all data units. Therefore, data are only discarded from the beginning of the queue and I do not see how that can change the sequence in any way?
Ad (6) – Clause 2.1.3.3.3 in the Simple DPP states: "The Service Provider shall process the data units sequentially in the order in which they were received." The following note was just intended to clarify that the term "sequentially" is meant to be taken literally. If this is not understood a s a specification, then I think that clause should be rephrased, because all reporting identified only works if that constraint is adhered to.
Ad (8) – There is no special diagnostic, but there is a notification being sent when the PS becomes interrupted while a data unit is processed and my argument is that the User can know why the locked state was entered. The notification is specified in clause 2.1.3.3.8.2 of the Simple DPP: "If the Production Status changes to 'interrupted' at a time where a data unit has started processing but has not completed processing or when at least one PROCESS-DATA invocation is queued for processing the Service Provider shall invoke the NOTIFY operation with the notification ‘production interrupted'." This notification is defined already at the level of the operation if I remember well.
Regards, Martin
-----Original Message-----
From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
Sent: 03 May 2013 15:23
To: Martin Götzelmann
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
Dear Martin,
Thank you very much for having reviewed the updates of the Forward Procedures. Please find below my responses, for convenience interspersed with your original message.
Simple DPP V12
MG: (1) Comment WH1: I do not understand why all queued PD operations
have to be checked if the provider verifies that the counter in a received
PD operation is greater than the previous one. The only case where this
can happen is when the number of PD stored is larger than the range
divided by the increment (assuming that the same increment is always
used). If the concern really is that a user application would use huge
increments provoking ambiguity then OK, let's go for an increment by 1 and
state the assumption that range is sufficiently large to ensure uniqueness
as this is done by CLTU.
WH: If we want to ensure uniqueness of the data-sequence counter value
such that any notification can unambiguously refer to the relevant data
unit, then we have to enforce this uniqueness by either checking any new
counter value against all entries in the Input Queue or by putting the
onus on the user requiring that the user ensures this uniqueness. All this
is due to leaving (in my mind unnecessarily) so much freedom to the user.
I fully support your suggesting to apply the same rules as in F-CLTU, at
least as long as we cannot identify a compelling reason for not being that
strict.
MG: (2) The paragraph following Comment WH 1 says “The ascending order
of the data-sequence-counter values shall only be verified when the
PROCESS-DATA invocation is to be inserted into the Input Queue. No such
check shall be performed when the invocation is extracted from the queue
for processing”
I do not understand why this is stressed – it should be clear from
section 2.1.3 that the check is applied when the data are added to the
queue. In any case, why should it be forbidden to repeat the check when
extracting the PD invocation from the queue – that would be silly because
it would give the same result but it would not do any harm.
WH: You are fully correct that this consideration does not apply to the
Simple DP procedure as the specification is abstract as the specification
of the behaviour in case of queue overflow is not part of this procedure.
I therefore shall remove that text from the Simple DP procedure. However,
in case of the Buffered DP procedure, these considerations apply since in
case of Input Queue overflow or because of expiry of the latency timer in
real-time mode data units will be discarded. Given the above mentioned
freedom granted to the user regarding the data-sequence-counter values, it
is conceivable that when applied at the queue output the algorithm
checking the ascending order will flag an out-of-sequence exception due to
the data units that have been discarded.
MG: (3) 2.1.3.2.4 states “A value shall be considered greater if the
increment with respect to the one received with the previous operation is
less than the range of the data-sequence-counter parameter.”
I do not understand why this is needed. How can the increment be larger
than the range? I am assuming that the range is the range of the type
definition – or is that wrong?
WH: Again, so far the procedure did not constrain the assignment of the
data-sequence-counter values in any way (except maybe that one can assume
some common sense). All this requirement does is to prevent an increment
that actually looks like going backwards. If we can agree to be as
specific as F-CLTU, all this will be ' water under the bridge' and we can
clean up the specifications.
Buffered DPP V12
MG: (4) 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, possibly delegating the definition to service management or by
a derived procedure.”
This is an inherited feature – why is this re-stated? Have you revised the
rules for handling inherited specifications in Bordeaux ?
WH: We did not change the rules for inherited behaviour in Bordeaux. In
that regard, we could definitely remove the text. I guess the reason why
it was put in is that the parent procedure states that it is up to a
derived procedure (or service) to specify this. However, the Buffered DP
procedure does not do that and a reminder may be useful for users of that
procedure.
Sequence Controlled DP procedure V12
MG: (5) Comment WH1: I am not aware of the rule that we should not
specify what the user does and I do not really understand why we should
not do this where a certain behaviour is expected. Here are a few examples
from the framework:
3.4.1.1 The Service User shall invoke the BIND operation to establish an
association with a Service Provider.
4.3.3.1.2.1 Except as provided in 4.3.3.1.2.3, the Service User shall
not invoke any further operations for this service instance until the
return from the Service Provider is received.
4.5.3.1.1 The Service User shall initiate the transfer of data using the
START operation including the selection criteria.
The identified specifications have been adopted from the CLTU book (see
3.6.2.5) with the difference that the CLTU book says “shall be set”
instead for “the Service User shall set” - this can of course be done, but
I do not really see the difference.
I concur that the 1.1.4.2.1 duplicates 1.1.4.2.3 and 1.1.4.2.2 duplicates
1.1.4.2.4 but I would rather remove the paragraphs on validation and just
add the corresponding diagnostic values, as this is done in the CLTU book.
WH: Valid point! I was coming from the fact that we definitely specify the
behaviour of the provider in the form of a state machine, but we do not do
so for the user. Looking at your examples I certainly agree that in
numerous cases it is more appropriate and useful to the reader to specify
what the user is expected to do rather than specifying what the provider
will do in case the user does not ' behave'. For the specific case, we
shall definitely remove the duplicated requirements and keep only one
version. I have no strong feeling about which variant we shall keep.
MG: (6) Comment WH3: The Simple DPP explicitly states that at most one
data unit can be processed at any time and in my understanding this
statement applies to all derived procedures unless it is explicitly
modified. This specification was added to the simple DPP after an
intensive discussion in Boulder as far as I remember.
WH: You are right that the Simple DP procedure contains such statement,
but only in a note, not in a requirement. Looking at the procedures, I did
not find an example that would exclude pipelined processing as long as
that is sequence preserving. I did not attend the Boulder meeting and
therefore do not know about any drivers regarding this limitation. If it
is confirmed, then the related update of the procedure is very simple -
just change 'data units' to 'data unit' in 1.1.4.6 b).
MG: (7) Comment WH4: This has been adopted from CLTU 3.6.2.7.5. I
believe to remember that this has been discussed several times in the
context of the SLE services, but the conclusion seems to be that the
specification should be retained.
WH: There is nothing wrong with the specification as such. However, I was
wondering what will happen with a real-world production engine. The risk I
see is that under this condition we always end up with the ' expired'
exception. It would be interesting to test this on existing F-CLTU
providers.
MG: (8) Comment WH5: I do not really see the problem. In all cases in
which the procedure enters the locked state, the Service User has received
a notification indicating the incident. Therefore there should be no
confusion if the diagnostic code just says “service instance locked”
WH: Possibly something went wrong when the various updates were done by
several people. If I read correctly what we have now, then no diagnostic
is specified for the case that production status becomes interrupted while
a data unit is being processed.
Best regards,
Wolfgang
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|Martin Götzelmann <martin.goetzelmann at telespazio-vega.de> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| 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: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|03/05/2013 10:56 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|RE: [Css-csts] Revised Forward Procedures for integration into the Framework |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|css-csts-bounces at mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
Dear Wolfgang,
Here are my comments - prepared of course in ignorance of the discussions on the Bordeaux meeting.
Simple DPP V12
(1) Comment WH1: I do not understand why all queued PD operations have
to be checked if the provider verifies that the counter in a received PD
operation is greater than the previous one. The only case where this can
happen is when the number of PD stored is larger than the range divided by
the increment (assuming that the same increment is always used). If the
concern really is that a user application would use huge increments
provoking ambiguity then OK, let's go for an increment by 1 and state the
assumption that range is sufficiently large to ensure uniqueness as this
is done by CLTU.
(2) The paragraph following Comment WH 1 says “The ascending order of
the data-sequence-counter values shall only be verified when the
PROCESS-DATA invocation is to be inserted into the Input Queue. No such
check shall be performed when the invocation is extracted from the queue
for processing”
I do not understand why this is stressed – it should be clear from
section 2.1.3 that the check is applied when the data are added to the
queue. In any case, why should it be forbidden to repeat the check when
extracting the PD invocation from the queue – that would be silly because
it would give the same result but it would not do any harm.
(3) 2.1.3.2.4 states “A value shall be considered greater if the
increment with respect to the one received with the previous operation is
less than the range of the data-sequence-counter parameter.”
I do not understand why this is needed. How can the increment be larger
than the range? I am assuming that the range is the range of the type
definition – or is that wrong?
Buffered DPP V12
(4) 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, possibly delegating the definition to service management or by
a derived procedure.”
This is an inherited feature – why is this re-stated? Have you revised the
rules for handling inherited specifications in Bordeaux ?
Sequence Controlled DP procedure V12
(5) Comment WH1: I am not aware of the rule that we should not specify
what the user does and I do not really understand why we should not do
this where a certain behaviour is expected. Here are a few examples from
the framework:
3.4.1.1 The Service User shall invoke the BIND operation to establish an
association with a Service Provider.
4.3.3.1.2.1 Except as provided in 4.3.3.1.2.3, the Service User shall
not invoke any further operations for this service instance until the
return from the Service Provider is received.
4.5.3.1.1 The Service User shall initiate the transfer of data using the
START operation including the selection criteria.
The identified specifications have been adopted from the CLTU book (see
3.6.2.5) with the difference that the CLTU book says “shall be set”
instead for “the Service User shall set” - this can of course be done, but
I do not really see the difference.
I concur that the 1.1.4.2.1 duplicates 1.1.4.2.3 and 1.1.4.2.2 duplicates
1.1.4.2.4 but I would rather remove the paragraphs on validation and just
add the corresponding diagnostic values, as this is done in the CLTU book.
(6) Comment WH3: The Simple DPP explicitly states that at most one data
unit can be processed at any time and in my understanding this statement
applies to all derived procedures unless it is explicitly modified. This
specification was added to the simple DPP after an intensive discussion in
Boulder as far as I remember.
(7) Comment WH4: This has been adopted from CLTU 3.6.2.7.5. I believe
to remember that this has been discussed several times in the context of
the SLE services, but the conclusion seems to be that the specification
should be retained.
(8) Comment WH5: I do not really see the problem. In all cases in which
the procedure enters the locked state, the Service User has received a
notification indicating the incident. Therefore there should be no
confusion if the diagnostic code just says “service instance locked”
Kind Regards, Martin
-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [ mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Wolfgang.Hell at esa.int
Sent: 27 April 2013 15:32
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Revised Forward Procedures for integration into the Framework
Dear CSTS WG Members,
As agreed with Margherita during the Bordeaux meeting, I have assigned highest priority to the consolidation of the three Forward Procedures so that these can be integrated into the Framework asap. I have uploaded the results of this activity to (Embedded image moved to file: pic01814.gif) The CCSDS Collaborative Work Environment (CWE) > Cross Support Services Area
(CSS) > Documents > CSS-CSTS > CWE Private > Working Materials > DPP Working Papers
The vast majority of the issues raised before and aty the Bordeaux meeting have been taken care of. A few minor points are addressed by means of comments in the documents. Given that the next scheduled meeting is not before June, I would appreciate if you could provide feedback via email so that I can close this activity and provide Yves with stable input to the Framework.
Best regards,
Wolfgang
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.
_______________________________________________
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