Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Tue, 8 Oct 2002 19:17:50 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2002 4:04 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                              (Tue, 08 
> Oct 2002 15:52:35)
> > [TOLGA]If to be as much similar to MTP2 is so important, 
> then it could be
> > also better to stick with T7 as it is in MTP2, afterall it 
> causes also
> > problems there, based on your previous messages.
> 
> You missed the point.  T7 does not cause problems for 
> standard MTP2: only
> if some fool introduces an artificial, a non-compliant, delay 
> into a link.
[TOLGA]Saying that unlikely cases are user error for MTP2 but should be
addressed for M2PA is not fair IMO. The counterpart of a compliant link is a
reasonable IP network with reasonable SCTP parameters.
> 
> On the other hand, M2PA's variable delay is expected and must 
> be properly
> accomodated.  To do that, using MTP2's T7 reset procedures 
> will not work well
> for M2PA.  A per-message approach is neccessary to accomplish 
> that (where it
> is not necessary for MTP2).
[TOLGA] M2PA's variable delay is within bounds. How much do you expect it to
be? If one wants it, there is nothing preventing to have a per message
approach but which scenario will it really handle significantly better?
Maybe just for the case, where peer M2PA trickles out ACKs? IMO, for M2PA,
crucial point is to have a suitable IP network.(BTW, I still think the
sentence you suggest is fine, because it is not restrictive)
> 
> > And one is free also for MTP2 case, to implement some 
> mechanism to deal with
> > that possible problem -for example like you described in one of your
> > previous messages-, if one wants to do so, there is nothing 
> preventive in
> > the protocol to do this.
> 
> Huh?  You shouldn't try to read an ITU-T document like an 
> IETF document.
> It is certainly not the place of Q.703 to attempt to 
> accomodate variable
> or excessive link delays artificially introduced into terrestrial
> transmission facilities.
[TOLGA] Regardless of the origin of the standard, I would think, if
something does not violate what stands in the standard, one is free to do
it, and how to meet performance requirements specified in other documents is
something implementation dependent.
> --brian
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 18:36:47 -0600

Tolga,

Tolga Asveren wrote:                (Tue, 08 Oct 2002 19:17:50)
> reasonable IP network with reasonable SCTP parameters.

Unless you can meet the transmission delays (including SCTP retransmission)
for the Basic procedure (about 30ms) then the procedure is not applicable to
M2PA.

> be?

MTP2's bounds for the basic procedure is about 30ms.  Can you make
SCTP guarantee 30ms?  (SSCOP can.)

> If one wants it, there is nothing preventing to have a per message

No, it is also for where SCTP trickles messages as well as acks.

> something implementation dependent.

Sticking junk in the link violates the model in Q.706.  The basic method
is no longer applicable.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 19:16:49 -0600

Tolga,

Let me take one final crack at explaining to you why SCTP cannot be used
in place of T7 and why T7 cannot be used on anything but a per-message
basis.  If this argument does not convince you it is probably beyond
explaining to you.

Set SCTP Path.Max.Retrans to 1, set Assoc.Max.Retrans to 1, set RTO.Min
and RTO.Max and RTO.Initial to 150ms.  Set Sack delay to 75ms or zero
for that matter.  The SCTP transmit buffer space must be set to something
reasonable (like 16k) otherwise SCTP will suffer dismal performance.

MTP3 delivers, for example, 10000 messages per second to M2PA.  This means
about 450,000 messages bytes per second which is not unreasonable (a single
high speed link can handle far more than this).  In a busy period, M2PA
delivers 10000 messages to SCTP (wide 24-bit SN window, 64k transmit buffer).
SCTP is in slow start and transmits 1 of the 10000 messages.  The remote
end acknowledges with a SACK (and an M2PA ack) in just under the 150ms RTO.
An so on for the next 9999 messages.  The last message in the queue will
take 1500 seconds to get acknowledged.  The association will not fail in
this period.  If M2PA is running a T7 timer in the fashion of MTP2, it will
be reset to 0.5-2.0 seconds every 150ms.  T7 will never fire.  However,
transmit congestion will eventually result or T2 Q.707 will will fire.
In that period of time several SLTM reattempts will have been performed by
MTP3 and MTP3 will fail the link after about a minute or so.  When the link
fails (whether on transmit congestion or SLTM failure), MTP3 will collect all
these messages from M2PA and place them on another link.  This is incorrect,
because almost all of the messages are out of date (upper layer ISUP/TCAP
timers have long expired). These messages should have cleared.  (Transmit
buffers are normally set several seconds deep in the expectation that T7
plus the transmit buffer depth will not queue outdated messages).

If T7 is per-message there is no problem: the link will fail at 0.5-2.0
seconds.

Why does this not happen for MTP2 or MTP3b?  Because there is no delay
(other than emmission time) between MTP2 and the link and the transmission
delay to the MTP2 peer is bounded (at less than about 30ms for basic
procedure).  Also, MTP2 is limited by the bit rate of the wire in transmitting
messages.  M2PA has no such limitations.  It can deliver many thousands of
messages to SCTP in a single burst all of which will be buffered for
transmission indefinitely and trickled to the wire according to SCTP's strict
congestion algorithm.

Could you fix this by setting SCTP's transmission buffer size to 45 bytes?
No, because SCTP performance would be extremely poor.  Bundling messages on
first transmission would become impossible and SCTP would degrade by placing
too many undersized packets in the network.

Do you understand yet?

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 8 Oct 2002 19:50:07 -0600

To put this thread to rest I propose the following statement in M2PA:

  If M2PA does not receive an acknowledgement for a message within period T7
  from the time that the message was assigned an FSN and delivered to SCTP for
  transmission, the sending M2PA MUST immediately place the link out of
  service.

Implement it how you like: per-message T7, SCTP lifetimes, PR-SCTP,
whatever.

--brian