Subject: Re: [Sigtran] Comment on M2PA - Slow Start

From: [email-masked]
Date: Tue, 23 Jul 2002 14:52:09 +0530

Hi ,

IMO sending SCTP heartbeat messages does not affect the SCTP slow start
algorithm. SCTP needs to send user data messages on the association to keep
association out of the slow start.  One option to achieve this can be to allow
filler bytes to sent in case of Link Status In-Service message and M2PA sends
them  during IDLE period.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 07/23/2002 01:05:22 AM

Please respond to [email-masked]

To:   Tolga Asveren <[email-masked]>
cc:   [email-masked] (bcc: Sandeep Mahajan/HSS)

Subject:  Re: [Sigtran] Comment on M2PA - Slow Start

Tolga,

Tolga Asveren wrote:                         (Mon, 22 Jul 2002 14:34:03)
> 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,
> >
> > 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).
> [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?

There is always SCTP heartbeat.

--brian

--
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 23 Jul 2002 04:18:23 -0600

Sandeep,

Also, MTP Level 3 will send SNTM message on a regular basis which
contains a test pattern.  This will avoid slow start as well because
the link can never be idle for long.  As long as the link is not
dropping packets, MTP3 SNTM should be sufficient to avoid slow start.
I don't see a need for additional protocol in N2PA for this.

--brian

[email-masked] wrote:                            (Tue, 23 Jul 2002 14:52:09)

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 23 Jul 2002 08:32:59 -0400

Sandeep,

I am also not sure whether sending SCTP heartbeat will avoid shrinking of
cwnd, that was the reason of my original question to Brian.
SCTP RFC says at the end of page87:
"When the endpoint does not transmit data on a given transport address, the
cwnd of the transport address should be adjusted to max(cwnd/2, 2*MTU) per
RTO."
So, if our heartbeat period is less than than or equal to RTO, will the cwnd
shrink or not? It is said just "data", does this include heartbeat or is it
specifically data from user? And if it shrinks, what is the reason for that?
What is the difference between sending actual user data or SCTP heartbeat
from congestion avoidance mechanism point of view, if they are sent with the
same period?

    Tolga

> [email-masked]
> Sent: Tuesday, July 23, 2002 5:22 AM
> To: [email-masked]
> Cc: Tolga Asveren; [email-masked]
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Brian F. G. Bidulock