Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Wed, 9 Oct 2002 09:58:21 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2002 9:17 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> 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.
[TOLGA] You forget to give the value for some real important parameters,
like what is your IP networks average RTT? I would say average 30ms.
> 
> 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.  
[TOLGA] Why 1 of the 10000? What is MTU size? Let's say 1500 octets. Let's
say average SCTP message size will be 70 octets. If you don't exceed
2*MTU=3000octets, initially you can send 42 messages, and with every
received SACK, cwnd will grow(there are cases where it also shrinks, but
this is off-topic and should be addressed separetly). Even if you take
average RTT 50 ms and roughly say initial cwnd will be 40 messages big, in
4RTT cwnd will be 640 messages big, but your data rate is 500 messages per
50 ms.And another point does MTP3 deliver 10000 messages instantly at time
t? I better would say 1 message per 0.1 ms. Also what happended to the
messages we sent during link alignment to increase cwnd size? (Still to be
honest, I would say cwnd shrinking might be problem for other reasons, but
this needs to be addressed separetly)
> 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
[TOLGA] That is another bad assumption. You assume an IP network with
average RTT of 150 ms. One better does not use such an IP for M2PA. Average
RTT of 30 ms is not unrealistic. 
> 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.
[TOLGA] If one likes, one can of course have T7 with per message approach,
but it won't help with a bad IP network. The point is, you are presenting it
as a magic solution, but it isn't. 
> 
> 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.
[TOLGA] To deal with this, one better implements a reasoanable congestion
indication mechanism in SCTP -which is implementation dependent-. cwnd
shrinking might be a problem for high data rates. But T7 is not the solution
for that. So, whenever there is high data rate(I believe it should be higher
than the one in your example) after a silent period, are we going to fail
the link? This wouldn't be a solution. cwnd shrinking/size requires some
more thinking and IMO is topic for another thread. 
> 
> 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?
[TOLGA]One can have T7 with per message approach and I don't see harm on it,
but I think you are giving too much credit to it and trying to address
SCTP/IP problems with M2PA T7 timer. Unless problems with cwnd are
addressed, it won't help too much dropping the link everytime. And for your
example above, if a correct calculation is done, one can see slow start
won't cause a problem, but this does not mean, that one can't invent cases
where it might cause problems -probably with higher data rates or with high
packet loss rates-.
> --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: Wed, 9 Oct 2002 10:31:42 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Oct 2002 09:58:21)
> > Let me take one final crack at explaining to you why SCTP cannot be used
> > 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

RTT under congestion is average 150ms.  Average RTT under normal
circumstances is not important to the example.

> > 
> > 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.  
> this is off-topic and should be addressed separetly).

Because all 42 messages don't arrive at once: they arrive 200 ns between
them.  SCTP launches the first one before the other 41 arrive.  When the
next packet is launched they may very well bundle: so I should say that
it takes 30 seconds instead of 1500 seconds?  The analsis still applies.

> Even if you take average RTT 50 ms and roughly say initial cwnd will be 40
> messages big, in 4RTT cwnd will be 640 messages big, but your data rate is
> 500 messages per 50 ms.

Err, no, because the RTT is right around 150ms: consider that every other
packet could require retransmission, keep us in slow start, yet not fail the
link.  The analsis still applies.

> And another point does MTP3 deliver 10000 messages instantly at time t? I
> better would say 1 message per 0.1 ms. Also what happended to the messages
> we sent during link alignment to increase cwnd size?

Either they didn't increase it, or a number of packet losses along the way
closed it back down.

> (Still to be honest, I would say cwnd shrinking might be problem for other
> reasons, but this needs to be addressed separetly)

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

> RTT of 30 ms is not unrealistic. 

The average RTT is not 150ms, that happens to be the prevailing RTT
at the moment (during congestion).  The anaysis still applies.

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

> as a magic solution, but it isn't. 

This is not a bad IP neetwork, it is one which has merely suffered--maybe
even temporary--congestion.  It does happen to even the best of IP networks.
If M2PA is to only run over a PCMIG backplane were are wasting our time here
in IETF.

> > (other than emmission time) between MTP2 and the link and the transmission
> > 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.

> more thinking and IMO is topic for another thread. 

SCTP's congestoin algorithm is non-negotiable: sliding window linear growth,
exponential backoff.  The RFC permits even faster backoff, but not more
agressive growth.  T7 is the solution to M2PA's problems.

> > 
> > 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?
> SCTP/IP problems with M2PA T7 timer.

Actually, T7 is used in this fashion exactly as intended in SS7.  It will be
the time that a message is allowed to live in M2PA RTB just as with MTP2 and
MTP3b.

> Unless problems with cwnd are addressed, it won't help too much dropping the
> link everytime. And for your example above, if a correct calculation is
> done, one can see slow start won't cause a problem,

Wrong. The analysis still applies, even if you bundle.

> but this does not mean, that one can't invent cases where it might cause
> problems -probably with higher data rates or with high packet loss rates-.

--brian