Subject: Re: [Sigtran] M2PA Changes for version 4 - Performance Monitoring

From: [email-masked]
Date: Tue, 5 Mar 2002 14:12:23 -0500

Tom and others,

It appears that most of the text in Section 4.1.6 (Error Monitoring) was
deleted in draft 4.  Does this mean that m2pa will not be doing any proving
and in-service performance monitoring, including no SRTT check?

If my interpretation is correct, it seems as though the general concept is
that SCTP will monitor its own performance and remove associations with
degradable performance, and m2pa will have a simplistic error monitoring
procedure that involves checking whether the SCTP association is up.  If
the SCTP association is up, its performance is assumed to be acceptable for
m2pa links.  This concept appears to be making a lot of assumption about
the underlying SCTP functions.

Can m2pa depend on SCTP to do the necessary performance monitoring of each
association (i.e., are there defined performance criteria at SCTP or  would
there be a need for SCTP  Extension to allow automatic removal and
reestablishment of SCTP associations based on specific performance criteria
(e.g., SRTT, retransmissions, gaps etc)?

Regards

Ray

                    Tom George                                                               
                    <Tom.George@al        To:                                                
                    catel.com>            cc:     Sigtran <[email-masked]>, (bcc: Ray P.   
                                          Singh/Telcordia)                                   
                    03/04/02 04:47        Subject:     [Sigtran] M2PA Changes for version 4  
                    PM                                                                       

Here are the changes in draft-ietf-sigtran-m2pa-04.txt (M2PAv4).

If anyone wants to study the changes in detail, I have a "diff" file I
can send.

Changes for the M2PA Interop Issues
-----------------------------------

All the major changes in M2PAv4 were identified in "M2PA
Interoperability Test Results and Issues"
http://search.ietf.org/internet-drafts/draft-george-sigtran-m2pa-interop-00.txt

That document lists M2PA issues and possible solutions. The numbering
here refers to the section numbers of that document.

2.1  SCTP Acknowledgement

There was inadequate support in the TSVWG for the changes needed to
support options 2, 3, and 4. Option 5, M2PA sequence numbers, was
implemented in M2PAv4.

2.2  Link Status Out of Service Message

An OOS was added to the Link Status message values.

2.3  Aborting an Association for Performance

The text recommending that M2PA abort an association for poor
performance was removed.

2.4  Aborting an Association for MTP3 Stop

Text about aborting the association was removed. Now M2PA goes to the
out of service state instead of aborting the association.

2.5  Failing a Link

See response to 2.4.

2.6  Order of Transmission

The bits in the Spare/PRI field were reversed. That has been corrected.

2.7  Local Processor Outage and Link Status Ready

If LPO occurs during alignment, the alignment procedure
continues. This was clarified.

2.8  Proper Stream for Proving Data Messages

Proving messages are now sent on the Status stream.

The Proving Data message is eliminated. The Link Status Proving
message serves its purpose.

2.9  Tuning SCTP Parameters

Suggested values for SCTP parameters will be published later, probably
in an applicability statement.

2.10 M2PA Keep Alive Message

It was not considered necessary to create a Keep Alive message at this
time.

2.11 Emergency Changeover for Japanese SS7

Support for the Japanese SS7 changeover was added to the changeover
section.

2.12 Eliminate Client/Server Distinction

The client/server distinction was removed. A suggestion was added on
how to avoid duplicate associations.

2.13 Resolving Normal and Emergency Proving

This was clarified in the alignment section.

2.14 Need Reference for Busy

This reference is no longer needed, since the SCTP congestion
procedure is not part of the Busy procedure.

2.15 Processor Outage and Busy in Various States

The alignment section includes statements about Processor Outage. I
did not see any other specific changes that were needed.

A more detailed list of changes:
--------------------------------

This is not a complete list of changes. I did not include minor
rewording.

1.6.1: Changed SCTP sequence numbers to M2PA sequence numbers.

1.6.2, paragraph "FISUs...": Acknowledgement is provided at M2PA level
now.

1.7.4, 2nd paragraph: Removed Proving Data messages.

2.1: Added "message class". This should have been there in version 3.

2.1.4: Removed Proving Data from list of types.

2.2: Added this section for the M2PA header.

2.3: Added M2PA-specific header to the message.

2.3.1, both diagrams: Order of PRI/spare fields is reversed.

2.3.2, 1st paragraph: Removed clause "except as modified later",
because it was not modified later.

2.3.2, list: Added Out of Service and In Service.

2.3.2.1: Link Status Proving message replaces Proving Data message.

3, definition of PROVING: Link Status Proving message replaces Proving
Data message.

3, Figure 7: Several changes because M2PA does not terminate the
association. T1 Expiry, Receive LS OOS, and T3 Expiry take M2PA to the
OOS state.

3, Figure 8: Several changes because M2PA does not terminate the
association. Removed Abort paths.

4.1.2, first few paragraphs: Rewrote this to eliminate client/server
distinction. If both ends know the endpoints, SCTP can prevent the
duplicate associations.

4.1.2, figures: Removed labelling of client and server.

4.1.3, paragraph "If timer T1 expires...": Add that M2PA sends the
Link Status OOS message.

4.1.3, paragraph "M2PA starts the proving period timer T2.": Removed
Proving Data messages. Removed M2PA checking SCTP performance.

4.1.3, paragraph "When the proving period timer T2 expires...":
Removed M2PA checking SCTP performance.

4.1.3, paragraph "M2PA shall stop timer T3...": Replaced Links Status
Proving Complete with Link Status Ready. Added sending Link Status
OOS.

4.1.3, paragraph "Note that if M2PA has already received...": Removed
M2PA checking SCTP performance.

4.1.3, paragraph "If M2PA receives a Stop command...": Added this
paragraph.

4.1.4, paragraph "When M2PA detects a local processor outage...":
Added last sentence: "M2PA shall stop receiving incoming messages from
SCTP."

4.1.4, paragraph "M2PA should periodically...": Clarified that this is
done only if link is in service.

4.1.4, paragraph "MTP3 may send a Flush Buffers...": Added sentence
about data retieval.

4.1.5: Removed references to congestion notification from SCTP.

4.1.5, paragraph "When the peer M2PA...": The link is taken out of
service instead of aborting the association.

4.1.5, paragraph "The peer M2PA shall cease...": M2PA shall cease,
instead of continue, transmitting messages.

4.1.6: Removed monitoring of SCTP performance.

4.1.7: Removed implementation note. The draft that was cited does not
really provide stream priorities.

4.2.3: The link is taken out of service instead of aborting the
association.

4.2.5, paragraph "M2PA shall detect transmit congestion...": Removed
references to congestion notification from SCTP.

4.2.5: Removed the "Note" paragraph about M2PA not discarding messages
because of congestion. This is an implementation issue.

4.2.6, paragraph "(1) buffer updating...": Changed SCTP to M2PA.

4.2.6, paragraph "Note that only User Data messages...": Removed
sentence about stream sequence numbers, since M2PA sequence numbers
are used now.

4.2.6, paragraph "M2PA's Sequence Numbers...": Replaced SCTP sequence
numbers with M2PA sequence numbers.

4.2.6, paragraph "For data retrieval, MTP3...": Replaced SCTP sequence
numbers with M2PA sequence numbers. Removed discussion about SCTP
gaps.

4.2.6, paragraph "If there are any messages on the M2PA...": Clarified
which messages should be kept, which should be discarded.

4.2.6, paragraph "Note: For the Japanese version...": Added this
requirement to retrieve all messages.

4.2.6.1: Replaced SCTP sequence numbers with M2PA sequence numbers.

5.1: Moved Emergency and Start in the diagram. Changed Proving Data to
Link Status Proving. Removed check on SCTP performance.

5.5: Removed SCTP-to-M2PA congestion notification. Changed aborting
association to going out of service.

5.6: Removed SCTP-to-M2PA congestion notification.

5.7: Changed aborting association to going out of service.

5.8: Removed step where M2PA looks for SCTP gaps, since SCTP sequence
numbers are not the basis for retrieval.

9.: Removed SCTP Extensions for Dynamic Reconfiguration of IP
Addresses and Enforcement of Flow and Message Limits" since it is no
longer referenced.

10.: Updated some addresses.

(end)

--
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* 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

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

---

From: Tom George <[email-masked]>
Date: Fri, 08 Mar 2002 18:05:23 -0600

Ray,

We discussed this at the M2PA Interop. Most of us thought that by
setting SCTP parameters such as RTO.Min, RTO.Max,
Association.Max.Retrans, HB.interval, SCTP would monitor its own
performance adequately. 

Of course, if someone thinks this won't work, now would be a good time
to speak up. 8-)

tomG.