Subject: AW: [Sigtran] M2PA Last Call Comment - LPO

From: Gaiser Franz <[email-masked]>
Date: Thu, 31 Jul 2003 09:47:34 +0200

Tom,

I think we need an additional remark to support the following situation mentioned by Andrew (see figure below):

To avoid that after CONTINUE at the right side the restarted T7 timer will expire (Data with fsn=1 has not been acknowledged) we should permit the Link Status Busy message to acknowledge outstanding User data messages, so that upon its receipt, T7 might not need to be started if all messages in the RTB are acknowledged by the LS PR message.

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)

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

Best regards, Franz

-----Ursprungliche Nachricht-----
Von: Tom George [mailto:[email-masked]]
Gesendet: Mittwoch, 30. Juli 2003 17:29
Cc: [email-masked]'
Betreff: Re: [Sigtran] M2PA Last Call Comment - LPO

Brian, Andrew, Franz, et. al.,

I changed the 2nd paragraph in 4.1.4 to this:

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

Here is the old paragraph for reference:
=====
When the local processor outage condition 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.
=====

Is this the only change that needs to be made from this discussion thread?

tomG.

Brian F. G. Bidulock wrote:
> Franz,
> 
> (2) is already stated.  I have no problem with adding (1) to the description
> of handling of buffers at the side experiencing processor outage.
> 
> --brian
> 
> Gaiser Franz wrote:                                                                 (Fri, 25 Jul 2003 13:33:55)
> 
>>Hi All,
>>
>>From a developer point of view I would prefer that the statements about
>>resync are described more precisely and not in a way that the developer has
>>to interpret it especially when he was not involved in the development
>>process of M2PA.
>> 
>>Why don't complement it with the additional remarks i.e. made by Andrew that 
>>(1) the BSN in the LS PR is set to the last message received from the M2PA. 
>>(2) the sender always increments the FSN by 1 when sending MSUs. 
>>
>>best regards, Franz
>>
>>
>>
>>
>>
>>-----Ursprungliche Nachricht-----
>>Von: Brian F. G. Bidulock [mailto:[email-masked]]
>>Gesendet: Donnerstag, 24. Juli 2003 18:11
>>An: Andrew Booth
>>Cc: [email-masked]'
>>Betreff: Re: [Sigtran] M2PA Last Call Comment - LPO
>>
>>
>>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)
>>
>>>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.
>>>
>>>Brian F. G. Bidulock wrote:
>>>
>>>
>>>>Andrew,
>>>>
>>>>Please see comments below...
>>>>
>>>>Andrew Booth wrote:                                                                 (Wed, 23 Jul 2003 21:58:07)
>>>> 
>>>>
>>>>
>>>>>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)                |
>>>>>   
>>>>>
>>>>
>>>>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).
>>>>
>>>
>>>Agreed, it is unlikely.  If SCTP parameters are set correctly it might 
>>>even be impossible.
>>>
>>>
>>>>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.
>>>>
>>>
>>>Yes I understand, though I think MTP3 T1 is 0.5 to 1.2 seconds.
>>>
>>>
>>>>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.
>>>>
>>>
>>>Agreed.  Should this be stated explicitly in M2PA?
>>>
>>>
>>>>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.
>>>>
>>>
>>>Agreed, the last FSN should be 1 (still invalid).
>>>
>>>
>>>>
>>>> 
>>>>
>>>>
>>>>>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) |                          |
>>>>>   
>>>>>
>>>>
>>>>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.
>>>>
>>>
>>>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.
>>>
>>>
>>>>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.
>>>>
>>>
>>>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
>>>
>>>
>>>>--brian
>>>>
>>>> 
>>>>
>>>>
>>>>>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
>>>>>
>>>>>Gaiser Franz wrote:
>>>>>
>>>>>   
>>>>>
>>>>>
>>>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>
>>>>>-- 
>>>>>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.
>>>>>
>>>>>   
>>>>>
>>>>
>>>> 
>>>>
>>>
>>>-- 
>>>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.
>>>
>>
>>-- 
>>Brian F. G. Bidulock
>>[email-masked]
>>http://www.openss7.org/
>>
>>_______________________________________________
>>Sigtran mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/sigtran
>>
>>_______________________________________________
>>Sigtran mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/sigtran
> 
> 

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 31 Jul 2003 01:54:33 -0600

Gaiser,

> or FISU as in MTP2. The BSN in the Link Status Processor Recovered
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> message is set to the FSN of the last User Data message received from
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the peer M2PA. The BSN value in the Link Status Processor Recovered
  ^^^^^^^^^^^^^^

--brian

Gaiser Franz wrote:                                                                 (Thu, 31 Jul 2003 09:47:34)
> To avoid that after CONTINUE at the right side the restarted T7 timer will
> expire (Data with fsn=1 has not been acknowledged) we should permit the Link
> Status Busy message to acknowledge outstanding User data messages, so that
> upon its receipt, T7 might not need to be started if all messages in the RTB
> are acknowledged by the LS PR message.
> 
> 

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