Subject: [Sigtran] M2PA Last Call Comment - LPO

From: Gaiser Franz <[email-masked]>
Date: Mon, 21 Jul 2003 13:07:09 +0200

Hi All,

implementing Processor Outage Handling of M2PA draft 09 the following questions came up:

The Processor Outage chapter 4.1.4 says

When the local processor outage conditions ends, M2PA shall send a Link
Status Processor Recovered message to its peer. This message is used
to signal in the end of the processor outage condition, instead of an
MSU or FISU as in MTP2. The BSN value in this message is used by the 
peer to resynchronize its sequence numbers, if this is required by
MTP2.

What does M2PA draft 09 with BSN in this context mean, is it (assume, MTP3 has send Continue Command)

(1) the FSN of the last received message before LPO or 
(2) the FSN of the last message in the incoming messages that were queued and unacknowledged
during the processor outage (with that the remote side can release the messages in its RTB) ? 

thanks
best regards, Franz 

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

---

From: Andrew Booth <[email-masked]>
Date: Wed, 23 Jul 2003 21:58:07 -0400

Hi Franz,

Before answering your question I'll ask another: do we really need to 
resynchronize sequence numbers in M2PA, or can we just mandate that the 
sender continues to increment the FSN on every transmitted MSU?
- This seems simpler than resynchronizing.
- Since M2PA does not retransmit, the motivation for resynchronization 
doesn't seem to be present as it does in MTP2.
- Some of the examples below give examples where resequencing can go 
wrong.  Although these situations are unlikely, the consequences are 
unpleasant.

Now for my best answer to your question: Option (2), but if there are no 
unacknowledged messages then the BSN should be set to the FSN of the 
last acknowledged message.
Note also that if the receiver of the LS PR uses the BSN to free 
messages in the RTB (as you indicated below) then they have to be extra 
careful when validating BSNs in ensuing Data messages that may have been 
sent before the LS PR. I don't think this is a good idea.

Some potential issues with resynchronizing sequence numbers:

Note that the sender of LS PR cannot know if the receiver will use the 
BSN to resynchronize sequence numbers or not, since it is the MTP in RPO 
that decides when RPO is "long duration" via the MTP3 T1 timer.
This leads to race conditions in which one side flushes and the other 
does not, though they are unlikely.  For example, the following could 
occur if an MSU was delayed longer than MTP3 T1 on the IP network:

     MTP3                  M2PA                        M2PA
       |                     |                          |
       |                     |<--Data (FSN 0)-----------|
       |                     |                          |
       |                     |                     +----|
       |----LPO------------->|                    /     |
       |                     |----------LS PO----/----->|
       |                     |                  /       |
       |                     |                 /        |<--Flush
       |----LPR + Continue-->|                /         |
       |                     |----LS PR------/--------->| resync FSN
       |                     |    (BSN 0)   /           |
       |                     |             /            |
       |                     |<--Data-----+             |
       |                     |   (FSN 1)                |
       |                     |                          |
       |             Discard |<--Data-------------------|
       |           (bad FSN) |   (FSN 0)                |

The following example could occur if the side in LPO flushes while the 
side in RPO does not (perhaps they have different T1 timer settings), 
and if the side in LPO sends a BSN different from the last received by M2PA:

     MTP3                  M2PA                        M2PA
       |                     |                          |
       |                     |<--Data (FSN 0)-----------|
       |                     |                          |
       |                     |                     +----|
       |----LPO------------->|                    /     |
       |                     |----------LS PO----/----->|
       |                     |                  /       |
       |                     |                 /        |
       |               To RB |<--Data---------+         |
       |                     |   (FSN 1)                |
       |                     |                          |
       |----LPR + Flush----->|                          |
       |                     |----LS PR---------------->|
       |                     |    (BSN 0)               |<- Continue,
       |                     |                          |   don't resync FSN
       |                     |                          |
       |                     |                          |
       |             Discard |<--Data (FSN 2)-----------|
       |    (expected FSN 1) |                          |
       |                     |                          |
       |             Discard |<--Data (FSN 3)-----------|
       |    (expected FSN 1) |                          |

I think this possible condition provides reasonable incentive to always 
set the BSN in the LS Processor Recovered to the last message received 
from the M2PA peer.  In that case, there doesn't seem to be any point in 
resynching sequence numbers, just let the peer increment the FSN on 
every MSU.

In summary, these examples are unlikely but why complicate things? 
 Unless there is a good reason to keep the MTP2 resynching procedures 
lets get rid of them in favour of the simpler approach: the sender 
always increments the FSN by 1 when sending MSUs.

Thoughts?
Andrew

-- 
Andrew Booth, Software Developer
Signaling Systems Group, Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 24 Jul 2003 04:08:19 -0600

Andrew,

Please see comments below...

Andrew Booth wrote:                                                                 (Wed, 23 Jul 2003 21:58:07)
>        |                     |<--Data (FSN 0)-----------|

This is not really probable.  This would mean that the MTP RPO timer
expires when the LPO timer hasn't (a very narrow window) and that the
Data (FSN 1) was delayed longer than the RPO timer (which shouldn't
really happen).

Set your SCTP parameters (or lifetimes) so that messages not
acknowledged within the RPO timeout will drop the SCTP association and
you won't have this problem.

Do you see?  The "long duration" of the procedure (T1 or about 1.0 to
2.0 seconds) is used so that old messages stored in buffers are not sent
later.  RTB clear is performed immediately before changeover (after T1
expiry).  One doesn't want a recovering processor to transfer old
messages after changeover has occured or a lot of missequencing is going
to happen in the SS7 network.

Now, if you have SCTP parameters set to allow messages to be buffered IN
THE NETWORK for longer than T1, you have a real big problem: both the
time-controlled changeover and controlled rerouting procedures will
result in missequenced messages, even without processor outage.

So, if you have a problem above, becuase your SCTP will not drop the
link before delaying a data message longer than T1, you have the greater
problem that every time-controlled changeover or controlled rerouting
procedure for those M2PA links are going to missequence messagses.

Therefore, you need to tighten your SCTP parameters.  If you cannot
(e.g. the outher end is a really bad implemetnation), you really need to
bring the link down when the duplicate FSN arrives.

I think you have an error here too: BSN 0 acknowledges the receipt of
data with FSN 0.  After the resync, the next data sent should have BSN
1.

>        |                     |<--Data (FSN 0)-----------|

Again, having one side flush without the other is a small time window,
however, why are you sending LS PR (BSN 0)?  I think you should send
LS PR (BSN 1) in this instance.  Then there is no problem.

MTP2 would send BSN 0 here, but it is also discarding messages with the
expectation of retransmission.  M2PA buffers but does not acknowledge
messages.  The purpose of delaying acknowledgement is so that the peer
M2PA keeps these messages in the retransmission buffer for changeover.
(Remember than some variants collect from the RTB instead of clearing
it, unlike ANSI).  But, for M2PA, the BSN should be incremented when
the data is buffered to accomplish what happens here.

So this one is not a problem either.

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Thu, 24 Jul 2003 11:01:02 -0400

Hi Brian,

I don't think synchronization of sequence numbers after PO is necessary 
or desirable in M2PA.  Can you see any advantage to it?

I'd like to highlight this point by bringing up your comment after 
example 2 below: in order to avoid potential race conditions the side 
sending LS Processor Recovered should set the BSN to the last FSN 
received by M2PA.  By setting the BSN in this way we expect is that the 
peer will continue sending FSNs "in sequence" i.e. that the 
resynchronization will not actually change the next FSN the peer will 
send.  If that's the behaviour we want, and I think it is, then I 
propose that we specify it directly rather than carry over an 
unnecessary procedure from MTP2.

More comments below.

>Data (FSN 1) was delayed longer than the RPO timer (which shouldn't
Agreed, it is unlikely.  If SCTP parameters are set correctly it might 
even be impossible.

>to happen in the SS7 network.
Yes I understand, though I think MTP3 T1 is 0.5 to 1.2 seconds.

>result in missequenced messages, even without processor outage.
Agreed.  Should this be stated explicitly in M2PA?

>data with FSN 0.  After the resync, the next data sent should have BSN
Agreed, the last FSN should be 1 (still invalid).

>LS PR (BSN 1) in this instance.  Then there is no problem.
I agree this is unlikely, but I don't think the time window is 
necessarily that small: if one side sets T1 to 0.5s and the other to 
1.2s you have 0.7s to hit this.

>So this one is not a problem either.
Agreed, it's not a problem, but it does highlight the point I made 
above: we should set the BSN so that when resynchronizing sequence 
numbers the peer doesn't actually have to change anything.  It seems 
strange to have an exchange of BSN values for this purpose.

Thoughts?
Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 24 Jul 2003 10:10:50 -0600

Andrew,

On the first point, performance related issues are outside the scope
of the protocol.

On the second point, nowhere in M2PA-09 does it say to stop incrementing
BSN.  Just to withhold acknowledgements and buffer during PO.  The
peer is welcome, as it says in M2PA-09, to resync off of the BSN in the
LPR.  The fact that it doesn't change the FSN for ANSI does not mean that
it is not performing the resynchronization.

Look at the resync wording in M2PA-09 again.

I don't think it need changing.

--brian

Andrew Booth wrote:                                                                 (Thu, 24 Jul 2003 11:01:02)

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