Subject: RE: [Sigtran] other processor outage race conditions (was "M2PA LS Ready at the end of Processor Outage")

From: "Davidson, Mark" <[email-masked]>
Date: Wed, 10 Aug 2005 15:13:52 -0500

Brian,

Thanks for your response.  A few more questions/comments.

>Davidson, Mark wrote:                         (Wed, 10 Aug 2005
08:52:17)
>> 
>> How can User Data be sent after processor outage indication?
>
>   While in local processor outage (LPO) condition:
>      ...
>      (c) M2PA SHOULD continue to transmit messages that have been sent
>          by its upper layer MTP3.
>
>That's how.
>

I sure hope MTP3 doesn't continue to send data after a PO.  I guess that
moving
status messages in front of data messages could create this condition
(again,
seems like self-inflicted pain).  But per 4.1.8, that's only true for
status
messages on stream 0, right? ("M2PA SHOULD give higher priority to
messages sent 
on the Link Status stream...")  So status messages on stream 1 (i.e. PO
related
status msgs) stay in order? So data is already sent. Really seems like a

"should not occur".

>> 
>> Except for requiring an LS Ready for PO recovery, is there any reason

>> not to simply follow the MTP2 spec on this?  Are there other problems

>> being solved by the processor outage procedures beyond those that
were 
>> self inflicted by sending processor outage indication on stream 0?
>
>Yes, the other problem being solved is the subtle difference between
>MTP2 and M2PA: M2PA cannot discard messages because they will never be
retransmitted.
>
>The above is an embellishment that we thought worth while: because M2PA

>can send a single LSPO where MTP2 sends continuous SIPO, it is possible
for 
>M2PA to clear any backlog of messages to the peer where MTP2 cannot.
>
>This reduces the number of messages to be changed over or flushed from
the 
>LPO end and is a good thing.

OK, I see how this could ease the pain in certain situations, but it
still
has to work with the backhoe type outage.  Link failure is much more
common
than MTP3 failure.

-Mark

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 10 Aug 2005 14:44:05 -0600

Mark,

Davidson, Mark wrote:                            (Wed, 10 Aug 2005 15:13:52)
> I sure hope MTP3 doesn't continue to send data after a PO.  I guess that moving
> status messages in front of data messages could create this condition (again,
> seems like self-inflicted pain).  But per 4.1.8, that's only true for status
> messages on stream 0, right? ("M2PA SHOULD give higher priority to messages sent 
> on the Link Status stream...")  So status messages on stream 1 (i.e. PO related

There are several cases where there are messages to send after LPO.

1) MTP3 cannot receive messages (LPO) but it can send them.

2) Messages are queued between MTP3 and M2PA and, although LPO has been
   signalled, M2PA continues to receive messages for transmission.

3) Messages are priority queued between MTP3 and M2PA.  Local processor
   outage is signalled with higher priority than messages for
   transmission.

4) There are messages in the M2PA TB waiting to be transmitted.

These are all very valid situations.

--brian

> >> being solved by the processor outage procedures beyond those that were 
> >can send a single LSPO where MTP2 sends continuous SIPO, it is possible for 
> >This reduces the number of messages to be changed over or flushed from the 
> OK, I see how this could ease the pain in certain situations, but it still
> has to work with the backhoe type outage.  Link failure is much more common
> than MTP3 failure.
> 
> -Mark
> 
> 
> 

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/