Subject: RE: [Sigtran] M2PA V6: T7

From: Tolga Asveren <[email-masked]>
Date: Wed, 9 Oct 2002 13:44:39 -0400

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 12:32 PM
> To: Tolga Asveren
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M2PA V6: T7
> 
> 
> Tolga,
> 
> Tolga Asveren wrote:                                          
>                        (Wed, 09 Oct 2002 09:58:21)
> > 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.
> 
> 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.  
> > [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).
> 
> 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.
[TOLGA]Why do the messages arrive with 200 ms between them? Because of
delayed ack? If so, one better turns it off or sets to a much lower value.
> 
> > 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.
[TOLGA]Those things might happen and it might shrink cwnd. But the correct
place to address them is in SCTP.It is not realistic to say that every other
packet could require retransmission, but even so, one can drop SCTP
association if there are too many retransmissions or if other bad things
happen too much. Such a SCTP implementation won't violate the protocol.
Even if you take RTT at that time around 150ms, I wouldn't think there will
be a problem (after 900ms cwnd will be bigger than data rate and can deal
with the backlog). 
> 
> > 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
> 
> > [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. 
> 
> The average RTT is not 150ms, that happens to be the prevailing RTT
> at the moment (during congestion).  The anaysis still applies.
[TOLGA] Even with RTT=150ms I don't think there will be a serious problem. 
> 
> > > 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. 
> 
> 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.
[TOLGA] Of course there might be congestion but it also will happen within
reasonable bounds. 
> 
> > > 
> > > 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] I am not speaking about SCTP's congestion avoidance mechanisms. What
I am saying is local SCTP congestion indication to SCTP user, i.e. to M2PA.
> 
> > [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. 
> 
> 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.
[TOLGA]As indicated above, I am speaking about local SCTP indication to the
SCTP user. T7 does not solve anything. Then whenever there is a congestion,
you will drop the link? Doing this just because T7 for one message expired
is too drastic. If cwnd is a problem, one has to find a solution for it,
some local congestion mechanisms/trying to increase cwnd size etc... In fact
in Telephony signalling Transport over SCTP Applicability Statement draft it
is stated that even SCTP congestion mechanisms may not be followed.
> 
> > > 
> > > 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.
> 
> 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.
[TOLGA] This is nowhere stated in the documents, this is more an
interpretation.
> 
> > 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.
[TOLGA]Even with RTT around 150ms, I don't think there is 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 12:59:16 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 09 Oct 2002 13:44:39)
> > > [TOLGA] You forget to give the value for some real important parameters,

I said above, "Set SACK delay to 75ms or zero for that matter."

> be a problem (after 900ms cwnd will be bigger than data rate and can deal

You don't understand:  the association is running marginal.  That is, 
there are enough packets dropped to shrink cwnd without dropping the
association.  This is always a possibility in SCTP.  A few packets dropped
ever so often will keep the congestion window closed but not drop the
association.  No setting of protocol parameters will change that.
These packets will trickle through at 150ms spacing without dropping
the association.  It is always possible to trickle through at RTO.Max
without dropping the association.  The association is throttled due to
congestion.  Nobody is made aware of the throttling.  It is not the
delay of the packet on the wire that causes the problem as much as the delay
of packets waiting for transmission.  I only see 3 choices: SCTP Lifetimes,
PR-SCTP, and per-message T7.

> [TOLGA] Even with RTT=150ms I don't think there will be a serious problem. 

Why not?

> [TOLGA] Of course there might be congestion but it also will happen within

In this case around 150ms for 30 seconds (but even 5 seconds would
cause a problem).  Not unreasonable.

> I am saying is local SCTP congestion indication to SCTP user, i.e. to M2PA.

SCTP has a mechanism called SCTP lifetimes and PR-SCTP.  Boht are optional,
so T7 is a better approach to accomodate all SCTP implementations.

> SCTP user. T7 does not solve anything.

Yes it does.  It solves the entire problem.

> Then whenever there is a congestion, you will drop the link?

If the link can not longer satisfy T7 (congestion is of a sufficient
magnitude and duration), the link will be put out of service, as it
must to meet MTP performance requirements.

> Doing this just because T7 for one message expired
> is too drastic.

No it is not.  It is not too drastic for MTP2.

> If cwnd is a problem, one has to find a solution for it, some local
> congestion mechanisms/trying to increase cwnd size etc... In fact in
> Telephony signalling Transport over SCTP Applicability Statement draft it is
> stated that even SCTP congestion mechanisms may not be followed.

Are you recommending that M2PA not be able to work over SCTP with
a standard congestion algorithm?

> [TOLGA] This is nowhere stated in the documents, this is more an

Its in the name "Excessive delay of acknowledgement".  All messages
live in the RTB while awaiting acknowledgement.  That's clear enough
to me.

> [TOLGA]Even with RTT around 150ms, I don't think there is a problem. 

There is still a problem.

--brian