Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue (fwd)

From: "Nitin Vairagare" <[email-masked]>
Date: Mon, 6 Oct 2003 17:25:29 -0500

Tom,

Thanks for the summary of this issue.

After the lengthy/useful discussion, I agree to the fact that,
at this stage it is hard to put any specific hard limit 
on how long an implementation should wait (in terms of 
time or number of messages). And it may not be good idea 
to put any such limits unless we have any specific 
operational data supporting it.

The main issue was to make implementers aware (prevent) of 
poor SS7 performance by withholding ACKs for longer duration. 
The issue has been addressed in your proposed text.

Thanks,
Nitin

-----Original Message-----
From: Tom George [mailto:[email-masked]] 
Sent: Monday, October 06, 2003 4:54 PM
Cc: [email-masked]
Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)

I will try to summarize my thoughts from this discussion.

1. M2PA should not wait 500ms to ack a message (except in cases where it
is required to withhold acks). This causes too many messages to
build up in the peer's retransmit buffer and degrades SS7 performance.
In the example from the plugtest, messages were being transmitted at
3500/sec, so in 500ms there were about 1700 messages in the RTB. If the
link fails, that is too many messages to retrieve for changeover.

2. Putting a 200ms limit on the acknowledgement is not a good solution.
If 1700 messages build up in 500ms, then 680 could build up in 200ms.
This is also a lot of messages to retrieve for changeover. Another
problem with the 200ms limit is that it gives the impression that it is
OK to wait that long, when it isn't. The implementors who claimed that a
500ms wait was compliant will probably claim that a 200ms wait is
compliant if that is the stated limit.

3. Any time limit on the M2PA acks would be very hard to test.

4. Besides the ack delay, there is also delay in the network, delay in
SCTP at each end, etc. The T7 timer is there to determine when
acknowledgements are being excessively delayed, regardless of the
reason.

5. The M2PA sending the messages should not rely on an acknowledgement
time limit at the peer to protect against excessive build-up in the RTB.
Even if the peer M2PA acks each message instantly, there can be delay
from other sources. In the absence of transmit congestion controls,
there can be up to
     (max transmission rate) * T7
messages in the RTB. The sender must use transmit congestion procedures
to prevent the build-up of too many messages in the RTB.

6. I am not trying to make up a new way of acking messages for M2PA. I
just want to imitate MTP2. MTP2 sends an ack on the next outgoing MSU,
or, if there is no MSU, FISU. M2PA should work the same way. If there is
an outgoing User Data message, use that to send the ack. If there is not
a User Data message to transmit, generate an empty user data ack message
in place of the FISU that would have been used in MTP2.

7. I do not see a problem with numerous empty ack messages being sent if
the message is acked quickly. If there are no messages queued up to be
sent, then presumably the network is capable of handling an empty user
data message to carry the ack.

8. With all of that said, here is what I would propose to replace the
"promptly" paragraph in 4.2.1. It is very similar to what Brian
proposed.

=====
When there is a message to acknowledge, M2PA MUST acknowledge the
message with the next User Data message sent.  If there is no User Data
message available to be sent when there is a message to acknowledge,
M2PA SHOULD generate and send a User Data message with no data payload,
without delay.  (In other words, in the case where MTP2 would
acknowledge a message with a FISU, M2PA SHOULD acknowledge the message
with an empty User Data message.) The FSN for this empty User Data
message is not incremented. It MUST contain the same FSN as the most
recently sent User Data message containing Data. Delaying of
acknowledgements can result in poor SS7 performance.
=====

9. The requirement for generating the empty User Data message is a
SHOULD. A good reason for not following this would be to process several
incoming messages so that they can be acknowledged with one outgoing
message. A bad reason would be to wait 500ms.

10. This is one of those performance-related issues that will be hard to
address until there is some operational experience. If that experience
tells us that the requirements are inadequate, this issue can be
addressed again before M2PA becomes a "standard".

* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   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: [email-masked]
Date: Tue, 7 Oct 2003 07:35:52 -0400

Hello Tom,

Excellent summary, and I like the new text.

Regards,

Jeff

                      Tom George                                                                                                  
                      <Tom.George@alca         To:                                                                                
                      tel.com>                 cc:      [email-masked]                                                          
                      Sent by:                 Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)                          
                      sigtran-admin@ie                                                                                            
                      tf.org                                                                                                      

                      10/06/03 05:53                                                                                              
                      PM                                                                                                          

4. Besides the ack delay, there is also delay in the network, delay in
SCTP at each end, etc. The T7 timer is there to determine when
acknowledgements are being excessively delayed, regardless of the reason.

8. With all of that said, here is what I would propose to replace the
"promptly" paragraph in 4.2.1. It is very similar to what Brian proposed.

=====