Subject: Re: [Sigtran] M2PA Flush Buffers

From: [email-masked]
Date: Wed, 5 Feb 2003 10:50:21 -0500

Hello Brian,

I agree with most of what you have said. It appears, however, that only
the "clear buffers" case for exiting processor outage is being addressed.
The more challenging case involves the "resume" (recovery prior to MTP3
T1 expiry and execution of timed-controlled changeover).

The following characteristics of M2PA v7 make support of processor outage
problematic:
1) M2PA maintains sequence numbers but does not retransmit, unlike MTP2.
2) Reception order of user data/ACKs vs. LSPO/LSPOE cannot be ensured
due to the use of multiple SCTP steams.

Perhaps I am missing something, but it seems to me that your statement

"- any data received by an M2PA peer experiencing LPO after an RPO
  has been sent MUST be discarded and MUST NOT be acknowledged."

guarantees that the M2PA link will go out of service for the "resume"
case of exiting PO. My understanding is that for this case, the
retransmit queue is not cleared and M2PA cannot retransmit. No re-synching
of sequence numbers should be necessary for this case.

Having said this, I think that while M2PA v7 clarity can be improved,
there is no issue with the draft's description of PO procedures. The
draft currently does not require that the receiver discard messages
during PO.

A solution for these issues is that upon PO onset (either local or remote)
M2PA begins buffering received user data without acknowledgement. This
can be accomplished by not receiving from SCTP stream 1, or by buffering
user data at the M2PA layer. Because the received messages are buffered,
it does not matter about the order of receipt of data/ACK and LSPO/LSPOE.
As discussed on the list previously, M2PA must continue to receive and
process messages on SCTP stream 0 (link status) during PO.

In the case of "resume" after PO, M2PA should simply unbuffer the
received user data messages, validate them, acknowledge receipt, send them
to L3, and begin transmitting as normal. No retrieval or rerouting occurs,
and no messages are lost.

In the case of "clear buffers" after PO, M2PA should flush the all
outbound and inbound queues (possibly including SCTP receive buffer),
and then re-synch the sequence numbers with the peer.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 02/05/2003
03:03:15 AM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    TOLGA ASVEREN <[email-masked]>
cc:    [email-masked]
Subject:    Re: [Sigtran] M2PA Flush Buffers

TOLGA,

TOLGA ASVEREN wrote:
(Wed, 05 Feb 2003 08:25:56)
>
> Tom,
> --- Tom George <[email-masked]> wrote:
> > Andrew,
> >
> > Thanks for the comments. I will gladly defer to
> > those with more SS7
> > smarts, but I think there is no case where the
> > receiver has to know the
> > order in which LS and User Data messages were sent.
> > MTP2 itself has
> > LSSUs jumping to the head of the line when they are
> > transmitted.
> >
> > So what do we do with User Data messages that are
> > received after a LS
> > PO? We can't just copy MTP2, since the same
> > situation does not occur. In
> > MTP2, receiving an MSU ends the RPO condition.
> >
> > The current M2PA does not say exactly what to do,
> > which I would
> > interpret (if I may "interpret" my own writing) that
> > the receiver should
> > go ahead and process the User Data messages. The
> > presumption would be
> > that they are valid messages sent before the RPO
> > occurred.
> [TOLGA]IMO it is better to mention this in the document. I have some more
> questions though:
> I assume even after receiving LS(PO) from the peer, M2PA continues to
> acknowledge received messages(?)
> Similarliy I assume during local processor outage, based on received
> acknowledgements buffers are updated(?) IMO, it might be good to clarify
> this in the text(if this is the case)
> What about T7 on the peer experiencing local processor outage? Will it be
> stopped or not? If the above is true, I would think it shouldn´t be
> stopped.
> In 4.1.4 there is a sentence
> "Alternatively, MTP3 may perform data retrieval as part of a changeover
> procedure."
> Are the described procedures in that sentence and flushing buffers really
> alternatives to each other?

To avoid mis-sequencing of messages, neither end should send or
acknowledge messages during LPO.

The receiver of RPO must not acknowledge any messages after the
receipt of RPO to remain consistent with Q.703 and interactions
with Q.704 (time-controlled changeover procedure).  The MTP
Level 3 suffering LPO must know that when LPO begins that
message transmission has ceased so that the time-controlled
changeover procedure time duration is correctly referenced
against the last message transmitted on the blocked link.

To remain consistent with ANSI T1.111.3, both the sender and
the receiver of RPO should re-synchronize sequence numbers
(acknowlege received messages awaiting ack) and cease
transmission of DATA.

Again, just as the side experiencing LPO must reference its
time-controlled changeover at Level 3 against the last message
sent on the blocked link, so must the side detecting RPO
reference its time-controlled changeover procedure against the
last message transmitted peer in RPO.

The peer sending RPO must stop its T7 timer as it cannot expect
an acknowledgement for any messages during RPO (see test case
3.4.1 in draft-bidulock-sigtran-m2pa-test-02.txt).  Both sides
also stop T6 and cease any busy condition (sends BUSY-ENDED if
BUSY was sent previously).

To summarize:

- any data received by an M2PA peer experiencing LPO after an RPO
  has been sent MUST be discarded and MUST NOT be acknowledged.

- the M2PA peer experiencing LPO MUST NOT send any data messages
  between sending PROCESSOR-OUTAGE and PROCESSOR-OUTAGE-ENDED

- the M2PA peer sending PROCESSOR-OUTAGE SHOULD resynchornize
  sequence numbers by acknowledging all outstanding received
  data.

- any data received by an M2PA after receiving PROCESSOR-OUTAGE
  and before receiving PROCESSOR-OUTAGE-ENDED from the peer
  MUST be discarded and MUST NOT be acknowledged.

- the M2PA peer receiving PROCESSOR-OUTAGE MUST NOT send any
  data until receiving PROCESSOR-OUTAGE-ENDED.

- the M2PA peer receiving PROCESSOR-OUTAGE SHOULD resynchronize
  sequence numbers by acknowledging all outstanding data
  received before receiving PROCESSOR-OUTAGE.

This is completely consistent with Q.703/T1.111.3 and has the
benefit that harmful interactions with MTP Level 3 will not be
caused by introducing unexpected behavior (i.e. sending messages
for seconds after MTP Level 3 expects that the link has blocked).

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 5 Feb 2003 12:24:16 -0800 (PST)

Jeff,
> process messages on SCTP stream 0 (link status)
[TOLGA] Tom's interpretation of text sounds a bit
better to me, i.e. processing and acknowledging user
data messages even during remote processor outage.
This might help for the case where a message
experiences retransmission and arrives after LS(PO).
If the acknowledgement is delayed till LS(POE) is
received, T7 might expire. Afterall I think it is not
a bad assumption to think that any data message
received between LS(PO) and LS(POE) is in fact either
sent before LS(PO) or after LS(POE). 
IMO it is better if M2PA is more clear about the
procedure to be followed during processor outage as we
can see during this thread, different people might
have different interpretations of the current text.
> "Brian F. G. Bidulock"
> <[email-masked]>@ietf.org on 02/05/2003
> 03:03:15 AM
> 
=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Feb 2003 14:27:58 -0700

jeffrey.craig,

[email-masked] wrote:                                             (Wed, 05 Feb 2003 10:50:21)
> M2PA begins buffering received user data without acknowledgement. This

Yes, of course.  I'm sorry, I don't know what I was thinking saying "dicard."
Yes, buffer and do not acknowledge.

 To summarize:
 
 - any data received by an M2PA peer experiencing LPO after an RPO
   has been sent MUST be buffered and MUST NOT be acknowledged.

 
 - any data received by an M2PA after receiving PROCESSOR-OUTAGE
   and before receiving PROCESSOR-OUTAGE-ENDED from the peer
   MUST be buffered and MUST NOT be acknowledged.