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

From: "Nitin Vairagare" <[email-masked]>
Date: Fri, 26 Sep 2003 09:29:20 -0500

Brian,

The proposed text looks more appropriate and will force implementations
to send the acks without delay. In addition it would be nice to specify
the exceptions like LPO or receive congestion in the same paragraph. 

Regards,
Nitin

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Friday, September 26, 2003 4:10 AM
To: Javier Kim
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] M2PA MSU_ACK frequency issue (fwd)

Javier,

200ms is too long.  Waiting 1 received message is too long.  The text in
M2PA-09 attempts to state the differences between M2PA and Q.703 with
regards to positive acknowledgment.  Q.703/5.2.3 says:

  "The receiving signalling link terminal acknowledges the acceptance of
   one or more message signal units by assigning the forward sequence
   number value of the latest accepted message signal until to the
   backward sequence number of the next signalling unit sent in the next
   signal unit sent in the opposite direction."

Now, Q.703 has busy transmitters, so if there are no MSUs available for
transmission in the opposite direction, then the next FISU to be sent
will carry the acknowledgment.  This means that the mean delay before
emission of an acknowledgment is the mean of the emission time for an SU
in the opposite direction.  For a 64kbs link that is idle in the
opposite direction with 1 flag between FISUs is about 375 microseconds
(yes, MICROseconds).  Because the delay depends on SU emission time
only, the delay for a 2.048Mbps Annex A link (idle in the opposite
direction) is 11.7 microseconds.  The mean emission times and the
acknowledgment delay associated with mean emission times based on MSU
size and Erlang loading of a signalling link are considered in the
queuing model for MTP presented in Q.706.  Queuing models (Q.706) for
MTP assume 30ms loop delay for terrestrial links INCLUDING PROCESSING
TIME AT THE SIGNALLING TERMINAL (caps for emphasis).

If a Q.703 (or Annex A) link waited 200ms to acknowledge receipt of an
MSU it would destroy the usability of the link for use with Q.704.  So
what makes you think that 200ms is any better than the 500ms experienced
in inter-op testing?  Either would make an M2PA link unsuitable for
replacement of even a 64kbps Q.703 link, regardless of the performance
of the underlying SCTP transport.

Back to Q.703/5.2.3 above and M2PA-09, M2PA-09 says:

  "If there is no other User Data messages 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."

This is an attempt to mimic the passage from Q.703/5.2.3 above given the
consideration that M2PA does not have a busy transmitter (i.e. does not
idle FISUs).  So the idea is to say that the acknowledgment goes out on
the next DATA message available for transmission (to SCTP) and that if
one is not immediately available for transmission (to SCTP), then a
DATA-ACK message must be generated and transmitted (to SCTP).

So, I disagree strongly with any statement that would give one the
impression that waiting any amount of time is acceptable.

Considering this, I don't see a problem with rewording the passage from
M2PA-09 as follows:

  "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 MUST generate and send a User Data message with no
   data payload, without delay.  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."

I believe that makes the statements be closer to the effect of the
statements in Q.703.  An implementation that artificially waits 2ms to
acknowledge a message is in violation of both.

So, you see, stating 200ms would not improve M2PA, it would degrade it.
It was always the intention that M2PA generate a DATA-ACK to carry the
acknowledgment that Q.703 would carry in the next outbound FISU.  If you
can propose better language to that effect, please send it without delay
;)
But waiting even so much as 1ms, or even 1 inbound message, to generate
an acknowledgment is IMO unacceptable.

On the other side, the sender had better be prepared to buffer T7 worth
of messages at maximum throughput or institute N2 RTB full and Q.704
transmission congestion procedures in conformance with the portions of
Q.703 that are unchanged by M2PA, because it may take SCTP just less
than T7 to deliver the ack.  (See test case 3.8.3 "Check RTB full" in
draft-bidulock-m2pa-test-04.txt and test case Q.781/8.3.)  At 20Mbps
effective throughput and 64 byte User Data messages with a 1.0 second
T7, that would mean buffering about 40,000 messages awaiting ack in the
RTB or instituting RTB full and Q.704 transmission congestion procedures
before that point (setting N2 < 40,000).

Taking the link out of service at 1500 messages isn't acceptable either.
If your RTB holds a maximum of 1500 messages, set N2 to a maximum of
1500.  If your RTB is byte limited instead of message limited, use N1.
Set your Q.704 transmission congestion thresholds based on TB, TB/RTB or
RTB occupancy appropriately as well to signal congestion before
congestion discard occurs.  (Note that with the "Check RTB Full" test
cases, the link must remain in service.)

--brian

Javier Kim wrote:
(Thu, 25 Sep 2003 18:01:54)
> 
> Brian,
> 
> The proposed text is offered for section 4.2.1. Are you suggesting to
> add Q.2110(MaxPD, etc) style method in the M2PA draft?
> 
> 200ms is proposed to set maximum time for INFO_TRANSFER state, not in
LPO
> or any other exceptional states, which should be discussed elsewhere
in
> the draft anyway.  Rationale is that in one hand, we don't want
penalize
> implementaions that wish to wait for a reasonable time for ourgoing
> MSUs from MTP3, and  the other hand, we don't want to accumulate too
many
> MSUs queued in the re-transmission queue either. The proposed text
will
> allow to send MSU_ACK as frequently as or as fast as one elects to do
so. I
> believe that 20 or 30ms is too short.  We don't want to agrevate
throughput
> by specifying shorter timer than SCTP's.  I welcome your porposal for
> reasonable timer value.
> 
> 
>  The actual event experienced during the plugtest 'forced' us to wait
> 500ms.  Nobody violated any rule described in the draft v09, it led to
> unacceptable situation.  How are we going tell that the implementation
is
> sloppy or bad?  As far as I can see,  they have violated nothing.
Without
> a specific method, it did not work, and it will not work, no matter
how
> many times or how loudly we repeat the word "promptly".
> 
> Yet, I need to hear one compelling reason why we don't want to improve
the
> draft by adding a simple and straight forward rule.  A protocol
without
> specific rule to cover problematic senario like this, only promote
> on-going IG, and diminish its applicability.  Why bother?
> 
> Best regards,
> 
> Javier
> 

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

_______________________________________________
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: Javier Kim <[email-masked]>
Date: Fri, 26 Sep 2003 14:25:30 -0700 (PDT)

> Date: Fri, 26 Sep 2003 09:29:20 -0500

Hi all,

We seem to be having a problem in resolving a clarification of the ACK
procedure for M2PA.  What is at stake is some fairly ordinary concerns
for the regular or exceptional operating situations for the operation of
the protocol.  Both regular and exceptional protocol situations must be
covered, but an unreasonable burden of overhead should not be introduced
into the standard at this time (or any time).  Particularly changes should
not be done for no or negligible benefit.

There is a proposal to send ACKs with ordinary data MSUs or in the absence
of outbound data MSUs, ACK with an zero-length MSU after reception
of at most 8 received MSUs or the passage of 200mS whichever comes first.

With respect to the recent remarks concerning the pressing need for
immediate M2PA acknowledgment packets, the comment is largely without
insight into how real protocol stacks work in real time.  When receiving
an MSU, the majority of cases stacks have no queued nor unsent outbound MSUs.
Therefore nearly all received MSUs would result in a needless ACKs were
they to be required IMMEDIATELY.  However, typically within microseconds
an MTP3 or higher layer response will likely arrive at M2PA that can carry the
same ACK information in a user content carrying MSU (obviating the separate
ACK).

The proposal to always ACK when the M2PA layer has no data waiting to
send is un-insightful of this last point and therefore "wastes" the
link and host bandwidth by not postponing the ACK a very short interval.
Further the writer confuses the situation by stating "that delaying ACKs
would degrade M2PA...".  This couldn't be further from the truth.  It is
precisely the same reason that SCTP delays SACKs (so that immediately
forthcoming response DATA chunks may carry a SACK) to not waste bandwidth
and CPU perturbation.  There is no loss and no degradation in a short
delay with only a few intervening received MSUs until a response (which
is almost surely forthcoming) arrives.  The savings to M2PA and the
underlying machine is very substantial (up to 50% reduction of overhead)
and the most of the unlikely penalty is 1 to 8 MSUs stored in the sending
host's retransmit buffer pending retrieval in the rare event of link
loss and changeover.

The writer points to degradation.  Where is the degrading?  At the worst
case (I suggest a brief review of mini-max principles)  0-7 messages can
be retrieved rather quickly by the sender.  However, of significant
interest to protocol designers is the average or nominal case of
routine operation.  Therefore, to saddle M2PA  with a certain 30-50%
packet overhead (IMMEDIATE acknowledgment overhead) forever is a real
and certain degradation.

Best regards,

Javier