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

Fri Feb 17 05:34:52 EST 2012

John,

I understand your considerations, but I do not completely agree with the
conclusion that you draw. I'm not aware of any implementation that supports
the provider initiated BIND of the return services and therefore in what
follows I ignore the case where the provider invokes a confirmed operation.
This is to focus on the case that is really relevant in practice.

I completely agree that the return time-out parameter will be disregarded by
the service provider with the exception of the case that the user invokes the
XXX-GET-PARAMETER selecting that parameter.

I further agree that the user is free to invoke the PEER-ABORT at any
convenient point in time. The difference is that in case of the time-out
triggering this happens automatically and at least on our system the
appropriate warning is displayed to the link operator. I know that strictly
speaking we do not specify the SLE user behavior, but all implementations I
have seen have taken this into account and any new attempt to bind will start
from the correct protocol state.

The other advantage of this parameter being there is that it kind of forces
the parties agreeing on (cross-)support to think about an appropriate value
for the specific peering. In practice, the key driver for setting this
parameter is actually not SLE related, but how the underlying ground comms
architecture looks like and in particular how rapidly the failure of the
prime link will be detected and the backup link is put in place. One will in
general agree on a value that will ensure that the SLE associations remain
intact when a comms fail-over takes place.

I fully agree that so far we do not have come up with any provider invoked
confirmed operations (although for a while we discussed if for accountability
reasons the XXX-ASYNC-NOTIFY should not be a confirmed operation) and as a
consequence the state table row for the ' return-timeout-period timer <n>
expired' event should be removed. For the reason outlined above I would
prefer keeping it as managed parameter.

I agree to put on our ' to do' list that we remove the single quotes both in
3.3.1.3 and 4.1.3.

Best regards,

Wolfgang

  From:       "John Pietras" <john.pietras at gst.com>                                                                                       

  To:         <Wolfgang.Hell at esa.int>, <css-csts at mailman.ccsds.org>                                                                       

  Date:       16/02/2012 23:08                                                                                                            

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

  Sent by:    css-csts-bounces at mailman.ccsds.org                                                                                          

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_______________________________________________
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.