Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue

From: [email-masked]
Date: Thu, 25 Sep 2003 07:47:42 -0400

Hello Tom,

I think the current draft text sufficiently addresses the ACK frequency
issue.

Regards,

Jeff

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

                      09/24/03 11:31                                                                                              
                      AM                                                                                                          

MTP2 is always transmitting something (MSU, LSSU, FISU), so it will
(almost) immediately ack an incoming MSU. M2PA, on the other hand, is
not transmitting continuously. So I can see a need for a requirement
that M2PA not delay acknowledgement too long.

But how should the requirement be stated? We already have a non-specific
statement in the draft (4.2.1):
"This message SHOULD be sent promptly in order to prevent poor SS7
performance."

If you want something more specific, it would be something like this:

=====
M2PA SHOULD acknowledge a received User Data message within 20ms.

M2PA SHOULD NOT allow more than 8 messages to be unacknowledged at any
time.
=====

But there would be exceptions to this, since in some cases M2PA does not
ack incoming data messages (LPO).

How much more helpful is it to make a more specific than to just say
"promptly"?

tomG.

Nitin Vairagare wrote:
> Brian,
>
> Your inputs are helpful to those poorly written implementations and
> provide ways to defend themselves, however, unless standard enforces
> constraints regarding acknowledgements, there will always be such
> poorly written implementations. And we all agree that those
> implementations are dangerous to networks.
>
> Regards,
> Nitin
>
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Monday, September 22, 2003 2:35 PM
> To: Nitin Vairagare
> Cc: Tom George; [email-masked]
> Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue
>
> Nitin,
>
> Q.703 requires that *every* MSU be acknowledged.  The SDLs show MSUs
> being
> acknowledged immediately and never delayed.
>
> Any implementation that waits 0.5 seconds is just poorly written.
>
> There is, however, a way to defend yourself against an implementation
> that
> does this, at the cost of throttling the link.  That is to set your N1
> and N2
> values (see Q.703) to some tight values: such as 32 msgs and 1024 bytes.
> This
> means that a Q.703 conforming state machine will stop transmitting new
> messages when 32 messages or 1024 bytes of MSUs have been sent, until
> those
> messsages are acknowledged.
>
> You might want to make these even more restrictive, depending on the
> maximum
> throughput that you wish to sustain without acknowledgement.  You also
> might
> want to set your transmission congestion onset and abatement thresholds
> down
> lower than N2.
>
> For Q.2210 based links, there are similar transmit window configuration
> parameters.
>
> Buffering large amounts of data in the Transmit Buffer can be
> disasterous for
> SS7 in live networks.  Transferring full Transmit Buffers on changeover
> can
> lead to cascading congestive failure resulting in total network
> isolation.
>
> Because the transmitter already can enforce constraints in terms of both
> the number of outstanding messages (N1) and the number of bytes
> outstanding
> (N2) that are acceptable within a time period (T7), by configuration you
> can force whatever constraint you want on the receiver.  Therefore IMO
> it is
> not necessary to devise constraints for the draft.  It is sufficient to
> say
> that the receiver should acknowledge messages immediately, as the draft
> already states.
>
> --brian
>
> Nitin Vairagare wrote:                         (Mon, 22 Sep 2003
> 14:16:23)
>
>>Tom,
>>
>>I am copying my comments that I exchanged with you earlier...
>>
>>
>>Yes, But there are no rules to do it..
>>
>>As mentioned in original mail it happens only after
>>timeout occurs. This means the risk of holding lots of
>>messages in buffer (approx 1500 msgs for transfer rate of 3K and
>
> timeout
>
>>occurring at 0.5sec). Which is rare in MTP2 in the presence of Acks
>
> thru
>
>>FISUs?
>>
>>Synchronizing it with SCTP might be helpful...
>>
>>SCTP requires that in absence of data traffic
>>from receiver end to Sender, every other data message be
>>acknowledged or at the expiration of receive timer.
>>If we synchronize M2PA with SCTP then, SCTP do not need to
>>generate SACK for every other Data message also.
>>
>>In absence of any such formal rules, the loss of data is larger (when
>>M2PA thread/Process dies). Which could be easily restricted.
>>
>>Some formal rules in the M2PA standard may help synchronize the
>>implementations.
>>
>>Regards,
>>Nitin
>>
>>-----Original Message-----
>>From: Tom George [mailto:[email-masked]]
>>Sent: Monday, September 22, 2003 1:48 PM
>>Cc: [email-masked]
>>Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue
>>
>>Javier,
>>
>>This was worded non-specifically in the draft, section 4.2.1:
>>
>>=====
>>If there is no other User Data message to be sent when there is a
>>message to acknowledge, M2PA SHOULD send a User Data message with no
>>data payload. 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. This message SHOULD be sent
>>promptly in order to prevent poor SS7 performance.
>>=====
>>
>>Waiting 0.5 sec is way too long. On the other hand, even if there are
>>only a few messges (less than 8), it is still not good to wait 0.5
>>seconds to ack.
>>
>>To cover both cases, there would need to be both a time limit and a
>>number-of-messages limit.
>>
>>tomG.
>>
>>Javier Kim wrote:
>>
>>>Hi All,
>>>
>>>
>>>From the recent Plugtest in Sophia Antipolis it was observed that
>>
> some
>
>>>M2PA implementations didn't send MSU_ACKs except by long timer
>>
> trigger
>
>>>(.5 second).  On a 3000 message-per-second link this could lead to
>>>recovery queues of 1500 MSUs or more.  It was determined that more
>>>frequent MSU_ACKs would be better and add little or no overhead for
>>
>>most
>>
>>>bi-directional message flows.
>>>
>>>We suggest that the draft be amended to require an MSU or MSU_ACK be
>>>returned no less frequently than every 8 MSUs received.  This would
>>>keep the M2PA recovery queues shorter, and faster to process, in the
>>
>>event
>>
>>>of a change-over.
>>>
>>>Best regards,
>>>
>>>Javier Kim
>>
>>
>>--
>>* 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
>
>

--
* 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: Tom George <[email-masked]>
Date: Thu, 25 Sep 2003 10:22:16 -0500

I could go either way, but I would prefer to leave the draft as it is on 
this issue.

tomG.

> I think the current draft text sufficiently addresses the ACK frequency
   [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Sep 2003 11:46:53 -0600

Tom,

Ditto.

--brian

Tom George wrote:                                                                      (Thu, 25 Sep 2003 10:22:16)

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