Subject: [Sigtran] M2PA Proc Outage section

From: Tom George <[email-masked]>
Date: Tue, 11 Mar 2003 17:37:05 -0600

I have a question for all of you about that proc outage section: I have
both ends stopping T6 Busy. But I only have the RPO end stopping T7. Is
that right? I would think that if both ends stop transmitting/receiving
User Data, then both should stop T7.

tomG.

P.S. I will be at jury duty tomorrow (Wednesday). All of you please keep
discussing. Thanks.

-- 
* 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 USA, Inc. 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

---

From: "S Magesh" <[email-masked]>
Date: Wed, 12 Mar 2003 12:42:34 +0530

Tom

I agree with your statement.  We should stop timer T7 in the local side
also, since we stop (i.e buffered) receiving User Data Messages 
(it may be Ack. message or Actual Message) from the 
Remote End during processor outage.

The statement given by you in 

e-mail Subject: Revised section 4.1
under Section 4.1.4 Processor Outage

"Any User Data messages received from the peer MUST NOT be
acknowledged and MUST be buffered." 

looks confusing, since User Data Message is also used as an
Acknowledgement message.  (So in this case stopping T7 timer
will solve the problem by not taking the Link to Out Of Service, if
it expires, because the User Data messages received are buffered 
and not delivered to MTP 3).

Regards

Magesh

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Mar 2003 00:30:57 -0700

Tom,

I think that's ok.  IIRC the end suffering LPO stops sending
data when it enters LPO, however, this end still expects
acknowledgements within T7 for messages in flight (messages
within its RTB at the time of outage) or the link should be put
out of service.  The end not suffering LPO must still pass
received messages to MTP3 and acknowledge them (with FISUs).

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

---

From: Andrew Booth <[email-masked]>
Date: Wed, 12 Mar 2003 11:02:03 -0500

Tom, Brian,

The currently proposed text for RPO has the following directive:
 
 (b) Any User Data messages received from the peer after the Link
       Status Processor Outage MUST NOT be acknowledged and MUST be
       buffered.

With the proposed text, T7 should be cancelled also at the end in LPO. 
 Otherwise T7 could cause the link to fail if the LS PO is received 
before previously sent user data.

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: Tom George <[email-masked]>
Date: Wed, 12 Mar 2003 15:02:26 -0600

There might be a problem with the range for the T7 timer. We have it as
0.5 - 2 seconds, the same as MTP2. Suppose that T7 is set to 2 seconds,
and that a link is capable of sending a few thousand messages/second. By
the time T7 expired, there could be thousands of messages in M2PA's
retransmission buffer. This could make it difficult to perform
changeover within the required time (300ms, I think). 

If the lack of acknowledgements is due to a network problem, SCTP should
fail the association before T7 expires. Of course, that depends on how
the SCTP parameters are set, but I think it would be reasonable to set
them that way.

Maybe someone who has experience with ATM links can help here. Is there
an analog of the T7 timer? What is its range?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Mar 2003 15:59:12 -0700

Tom,

> changeover within the required time (300ms, I think). 

Proper settings of congestion onset and abatement will keep the RTB from
filling too deep.

Even 64kb/s links have the problem that, if you let the TB/RTB fill too
deeply too quickly, cascade failure will result on changover.

--brian

---

From: Tom George <[email-masked]>
Date: Thu, 13 Mar 2003 11:30:17 -0600

Brian,

OK. I am happy with that explanation. Thanks.

tomG.

"Brian F. G. Bidulock" wrote:
  [...] 
> deeply too quickly, cascade failure will result on changover.
  [...]