Subject: [Sigtran] M2PA 7 questions

From: Andrew Booth <[email-masked]>
Date: Wed, 05 Feb 2003 15:53:42 -0500

Hi All,

I was looking over M2PA draft 7 and I have a few questions.

3. M2PA Link State Control
SCTP Restart is not mentioned in the state transistion diagram for SCTP 
associations in Figure 8.  Is this an oversight, or intentional?  There 
don't seem to be procedures for SCTP Restart mentioned elsewhere either.

Timer T7
========
In section 4.2.1 it sounds like a per message timer, or even an interval 
e.g.
   Timer T7 provides an indication of excessive delay of
   acknowledgement. If the following conditions are true:

   (a) There is at least one message in the M2PA retransmit buffer.

   (b) The remote M2PA is not in a Busy condition (i.e., the local
       timer T6 is not running).

   (c) There is a message in the M2PA retransmit buffer that has not
       received an acknowledgement in the span of T7 since its last
       transmission.

   then M2PA SHOULD take the link out of service.

The interpretation of T7 as an interval (or just a condition on 
messages) is reinforced by the fact there are no references to starting T7.

On the other hand in section 4.1.4 there is a reference to stopping T7 
during processor outage.  In 4.1.5 there is the comment
   "The peer M2PA SHALL NOT fail the link due to expiration of timer T7
   excessive delay of acknowledgement (see section 4.2.1 Sending and
   receiving messages) while its T6 timer is running, i.e., while the
   other end is Busy."
There is no comment on how to handle T7 after Busy clears.  Is it 
appropriate to immediately check the conditions from 4.2.1?

Timer T6
========
T6 is stopped during LPO, there is no comment to restart it at the end.  
Conclude that LPO ends the Busy state.  Is this correct?

4.1.5
In MTP2 a receiver that is experiencing congestion stops acknowledging 
messages until Busy clears.  In M2PA neither the sender nor receiver 
seems to do anything differently than when one end is not congested 
(other than start T6 and refuse to fail the link because of T7).  Is 
this appropriate?

Thanks for any comments,
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.

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

---

From: Tom George <[email-masked]>
Date: Wed, 05 Feb 2003 17:23:17 -0600

Andrew,

Thanks for the comments. Replies below...

> don't seem to be procedures for SCTP Restart mentioned elsewhere either.

I don't see how SCTP restart would affect M2PA. 

> In section 4.2.1 it sounds like a per message timer, or even an interval

It is intended to be a per-message timer. 

> appropriate to immediately check the conditions from 4.2.1?

I see the problem. After Busy clears, you may have a some unacked
messages that have been waiting for longer than T7. It doesn't seem like
you would want to fail the link for that. So it looks like T7 should be
restarted when Busy clears.

> Conclude that LPO ends the Busy state.  Is this correct?

T6 is timing the other end's Busy condition, so it would seem that a
local PO should not end the Busy state. So if there is an LPR, I would
think M2PA should restart the T6 timer if the other end is still Busy.

> (other than start T6 and refuse to fail the link because of T7).  Is

I think there was a discussion about this a long time ago. SCTP has its
own congestion procedures. So the only thing I was trying to do with
"M2PA flow control" was make sure SCTP was able to fix the congestion
problem within a reasonable (T6) amount of time. 

> Andrew
  [...]

-- 
* 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: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Feb 2003 18:36:11 -0700

Tom,

Tom George wrote:                                                                      (Wed, 05 Feb 2003 17:23:17)
> restarted when Busy clears.

T7 continues to run while busy (but not while processor outage).  This
is the same as Q.703.  T7 expiry just does not fail the link while busy,
T6 expiry does.

> think M2PA should restart the T6 timer if the other end is still Busy.

No. Busy is cleared during processor outage because neither side should
be sending anything during processor outage and the busy condition can
no longer exist.  When recovering from processor outage, the busy condition
cannot exist because messages were not being sent.  Both T6 and T7 are
stopped and the busy condition is cleared when entering processor outage
state.  This is consistent with Q.703.

> problem within a reasonable (T6) amount of time. 

Neither end stops sending or acknowledging messages during the busy
condition.  The busy end is just given more time (T6 instead of T7) to
acknowledge.  This is consistent with Q.703.

--brian

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

---

From: Andrew Booth <[email-masked]>
Date: Wed, 05 Feb 2003 23:18:17 -0500

Tom, Brian,

Thanks for the comments.  More questions below.

>>I don't see how SCTP restart would affect M2PA. 
Should SCTP RESTART be a transition event to OUT OF SERVICE in Figure 7?
I think the following scenario is possible.

If M2PA peer A detects the loss of association before M2PA peer B and A 
immediately reestablishes the association, then the SCTP implementation 
at B could see this as an association restart instead of a lost 
association.  In this case (RFC 2960, section 5.2.4):

    -  Any SCTP DATA Chunks MAY be retained (this is an implementation
         specific option).

      -  A notification of RESTART SHOULD be sent to the ULP instead of
         a "COMMUNICATION LOST" notification.
     
     All the congestion control parameters (e.g., cwnd, ssthresh)
      related to this peer MUST be reset to their initial values (see
      Section 6.2.1).

      After this the endpoint shall enter the ESTABLISHED state.

Assuming that a RESTART indication is a transition event to OOS:
Note that if the SCTP implementation does retain data chunks then there 
could still be a fair amount of stale data to retransmitted.  I don't 
think this stale data should cause big problems, but it could slow down 
the alignment after a restart.

>is the same as Q.703.  T7 expiry just does not fail the link while busy,
Is it then appropriate to check the condition in 4.2.1 when Busy abates, 
to see if T7 has expired for any unacknowledged messages?  If so, is it 
worth stating explicitly?

Andrew

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Feb 2003 23:01:18 -0700

Andrew,

Andrew Booth wrote:                                                                 (Wed, 05 Feb 2003 23:18:17)
> the alignment after a restart.

The peer that gets the restart indication doesn't have to do anthing:
Look at both sides:

The side getting the restart indication, if it supports the optional
procedure of RFC 2960, it will allow the M2PA to continue and deliver
a restart indication; otherwise, it will typically disconnect the ULP
and provide another init indication.  The latter fall into the existing
procedures for loss of an association and starting an association.

The side restarting either is capable of continuing where it left off
(unlikely, it has closed the association and is reopening it: there is
no reason to do so unless the M2PA has crashed and restarted).  If the
side restarting is capable of continuing, it continues where it left off.
If it is not capable of continuiing, it follows the procedures for starting
a new association and sends alignment.

(IMO the first thing that an M2PA peer should do when forming the
association is send LS OOS.  This is reflected in in the test spec
draft-bidulock-sigtran-m2pa-test-02.txt.  That way, if MTP3 has not
issued the Start signal, the other end will know the state of the link
immediately.)

So, no procedures are required outside of the normal procedures.

I agree with Tom: I don't see how SCTP restart would affect M2PA.

> worth stating explicitly?

As stated in 4.2.1, if T7 has expired for any messages during the busy
condition, it does not take the link out of service.  T7 does not need
to be "checked" when the busy condition ceases: if T7 expires and there
is no busy condition the link should be taken out of service as proscribed
in section 4.2.1.

--brian

---

From: Andrew Booth <[email-masked]>
Date: Thu, 06 Feb 2003 10:03:05 -0500

Thanks Brian,

That makes sense to me.

Andrew