Subject: [Sigtran] M3UA-v02 Last Call Comment: ASP Up Procedure race condition.

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 8 May 2004 00:59:43 -0600

Text in the draft in section 4.3.4.1 ASP Up Procedures now states:

|   If an ASP Up message is received and internally the remote ASP is in
|   the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as,
|   an Error message ("Unexpected Message).  In addition, the remote ASP
|   state is changed to ASP-INACTIVE in all relevant Application Servers
|   and all registered Routing Keys are considered deregistered.
|
|   If an ASP Up message is received and internally the remote ASP is
|   already in the ASP-INACTIVE state, an ASP Up Ack message is returned
|   and no further action is taken.

Unfortunately, deregistering routing keys aggravates a situation with the
current RFC.  ASPSM and ASPTM as sent on separate streams.  ASP Up messages
can be resent any number of times if an ASP Up Ack is not received fast
enough.

Multiple ASP UPs can be sent, no the presumption that the peer M3UA has
crashed without dropping the SCTP association and previously sent ASP Ups
were somehow lost or discarded by the far end.  If multiple ASP Ups are
sent on stream 0, they can arrive out of order w.r.t ASP Active messages
sent on a stream other than stream 0.  This means that a subsequent
ASP Up can arrive after an ASP Active/Ack exchange on another stream.
Routing keys are registered on stream 0, therefore, REG REQ can only follow
the last ASP UP, but ASP Active/Ack can race ahead.

Because the ASP Active Ack can also arrive out of order at the ASP wrt
the ASP Up Ack and ERR messages described above, it is not possible for
the ASP to know whether AS was activated or cancelled by the ASP Up Ack/ERR.

Because presumably ASP Up can be lost and that's why multiples need to be
sent, it is not possible for the ASP to determine how long it should wait
for ASP Up Ack and possible ERR messages before it can be sure that it is
able to activate an AS.

This ASP Up procedure was intended so that if the ASP crashes and comes
back up without dropping the association, that the SGP would reset the
state of the ASP on the ASP Up; however, it did not consider race conditions
introduce by sending ASPTM on a stream other than stream 0.

An alternative that would remove the race yet allow the original intention
is for restarting ASPs to send ASP Down and receive an acknowledgement before
sending ASP Up.  Then the SGP can leave the ASP state alone when it receives
ASP Up regardless of whether the state of the ASP is ASP-ACTIVE or
ASP=INACTIVE.  This removes the race while allowing for the more exceptional
restart procedure.  In this case, the passage should be reworded as follows:

   If an ASP Up message is received and internally the remote ASP is in
   the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as
   an Error message ("Unexpected Message") and no further action is taken.

   If an ASP Up message is received and internally the remote ASP is
   already in the ASP-INACTIVE state, an ASP Up Ack message is returned
   and no further action is taken.

   IMPLEMENTATION NOTE:- If an ASP restarts without dropping the SCTP
   association to the SGP, it should send ASP Down and wait for an ASP Down
   Ack message before sending any other messags to the SGP.

This removes race conditions yet permits the more exceptional restart
procedure.  The ASP always knows that receive of ASP Up Ack/ERR does not
affect a change in state of the ASP and late responses to repeated ASP
Ups can be ignored.

Also, to handle messages in transit on restart:

   At the ASP, the ASP Up Ack message received is not acknowledged.
   Layer Management is informed with an M-ASP_UP confirm primitive.
>  If the ASP receives an ASP Up Ack message without having sent an ASP
>  Up message, the ASP should now consider itself as in the ASP-INACTIVE
>  state.

>  If the ASP was previously in the ASP-DOWN state, the ASP should then
>  initiate procedures to return itself to its previous state.

This removes races from the ASP Up Procedures and streamlines overheads
for the more normal cases while still permitting the exceptional restart
case to be handled.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran