[Css-csts] Impossible/unenforceable return timeout peer-abort?

[John Pietras]

Wolfgang,

In a telecon today with people who are writing requirements for SGSS,
the question arose about how the return-timeout-period managed parameter
is determined and set for SLE transfer service instances. That parameter
is defined as "the maximum time period (in seconds) permitted from when
a confirmed [operation name] operation is invoked until the return is
received by the invoker" and points to section 4.1.3, which states "for
confirmed operations, if the invoker does not receive the return from
the performer within the return-timeout-period specified by service
management, the invoker shall abort the association by invoking the
XXX-PEER-ABORT operation with the diagnostic parameter set to 'return
timeout'. I have come to the conclusion that for all practical purposes
it is a meaningless parameter.

 

Let's first consider the case of user-invoked operations. In practical
terms, the managed requirement is meaningless - the user is free to
peer-abort  the association whenever (or to *not* peer-abort if a return
is not received within a certain amount of time).

 

The only way that this timeout is enforceable is when it applies to a
provider-invoked confirmed operation. 

 

For FCLTU and FSP, there are no provider-invoked confirmed operations.
In the state tables (which are specified to be for "provider behavior"),
the 'return-timeout-period-timer <n> expired' event (row 9 in FCLTU, row
11 in FSP) is impossible and should be removed from those states tables,
and return-timeout-period should be removed as a managed parameter.

 

RAF, RCF, and ROCF theoretically can have a provider-initiated BIND, and
the state tables do reflect that possibility. However, as you know, the
SLE API does not support provider-initiated binding, nor are there any
known implementations (API-based or otherwise) that support it. For SGSS
in particular, they are following the trend and supporting only
user-initiated binding. So practically speaking,  rows 1-5 of the state
tables for RAF, RCF, and ROCF are never triggered. 

 

Am I missing something that justifies keeping this timeout for FCLTU and
FSP, and for user-initiated RCF, RAF, and ROCF service instances? Since
return-timeout-period is retrievable via the GET-PARAMETER operations,
values for these parameters are presumably being stored by the existing
implementations of SLE transfer services. Does the provider
implementation do anything with those values other than echo them back
to user when requested via GET-PARAMETER?

Finally, for all of the SLE services, the NOTE in section 3.3.1.3 uses
the phrase "'missing return' timeout and section 4.1.3 uses the phrase
"'missing return' event". The single quotes around 'missing return'
implies a formally defined event, but there are no events so named.

 

Best regards,

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120216/ca2e042f/attachment.html