Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue

From: "Nitin Vairagare" <[email-masked]>
Date: Tue, 23 Sep 2003 09:42:49 -0500

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

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

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

---

From: Tom George <[email-masked]>
Date: Wed, 24 Sep 2003 10:31:44 -0500

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.

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