Subject: [Sigtran] Comment on M2PA - Slow Start

From: [email-masked]
Date: Fri, 19 Jul 2002 18:52:44 -0400

Tom and others,

Section 2.3.2.1 of m2pa draft 5 indicates that link status proving is used
to take SCTP through the slow start period.  However, the document does not
address how slow start would be addressed during changeover.  In the SS7
environment traffic from the affected link is redistributed on the other
links within a link set or combined link set during a changeover.
Therefore, it is likely that SCTP slow-start will have adverse impacts on
the volume of queued messages and link output delays. The Telephony
applicability statement indicates that some telephony signaling application
may choose to relax the congestion control rules of SCTP.  However, the
applicability document does not provide explicit guidance regarding how
this is done.  This is an issue that needs to be addressed for m2pa.

Regards
Ray

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

---

From: Tom George <[email-masked]>
Date: Fri, 19 Jul 2002 18:28:13 -0500

When I brought this up on the TSVWG list, I was told that slow start was
absolutely, positively required. 

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 12:02:01 -0600

Ray,

As slow start is performed by the sender and there is no protocol part
for congestion control (unless maybe you consider ECN), avoiding slow
start is implementation dependent (as is fairly stated in the AS).  If
you want to turn off your slow start or use the hearbeat mechanism to
keep an idle association out of slow start, your are welcome to try.  I
would be careful with the former (shutting off slow start) as the
congestion consequences could be disasterous.  Heartbeat is fairly safe,
but wasteful of bandwidth.  These are SCTP issues well outside the scope
of M2PA.  It was one of my original concerns with SS7 transport over
SCTP that SCTP could not make any guarantees whatsoever concerning the
timeliness of delivery of messages.  It is very difficult to set an
upper bound on the delay experienced by a message (slow start or not).

--brian

[email-masked] wrote:                 (Fri, 19 Jul 2002 18:52:44)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 22 Jul 2002 14:34:03 -0400

Brian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Brian F. G. Bidulock
> Sent: Monday, July 22, 2002 2:02 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sigtran] Comment on M2PA - Slow Start
>
>
> Ray,
>
[TOLGA] Sending BEAT might sometimes be usefull to keep an idle association
out of slow start for M3UA, but for M2PA, is there a corresponding
message/mechanism?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 22 Jul 2002 12:35:22 -0600

Tolga,

Tolga Asveren wrote:                         (Mon, 22 Jul 2002 14:34:03)
> out of slow start for M3UA, but for M2PA, is there a corresponding

There is always SCTP heartbeat.

--brian

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

---

From: Tom George <[email-masked]>
Date: Thu, 25 Jul 2002 12:44:50 -0500

Brian,

Which AS says this? I could not find it in the SCTP AS or the Signaling
Transport over SCTP AS.

> start is implementation dependent (as is fairly stated in the AS).  If
  [...]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 25 Jul 2002 12:23:03 -0600

Tom,

Avoiding slow start is "defeating congestion controls".

--brian

Tom George wrote:                                             (Thu, 25 Jul 2002 12:44:50)

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