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

From: [email-masked]
Date: Wed, 24 Jul 2002 19:06:13 -0400

I am not sure whether resolution of this issue was reached.  However, as a
minimum I would propose that a statement be included in m2pa indicating
that method to reduce the impact of slow-start during changeover is
implementation dependent.

Thanks
Ray

                    "Tolga                                                                             
                    Asveren"             To:     [email-masked]                                      
                    <tolga.asvere        cc:     (bcc: Ray P. Singh/Telcordia)                         
                    [email-masked]>           Subject:     RE: [Sigtran] Comment on M2PA - Slow Start       
                                                                                                       
                    07/23/02                                                                           
                    11:57 AM                                                                           

Sandeep,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, July 23, 2002 11:12 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: RE: [Sigtran] Comment on M2PA - Slow Start
>
>
>
>
> Hi Tolga,
>
> Please see my comments below.
>
> Best Regards,
> -Sandeep
>
>
>
>
>
> Tolga Asveren <[email-masked]> on 07/23/2002 09:25:45 PM
>
> To:   [email-masked]
> cc:    (bcc: Sandeep Mahajan/HSS)
>
> Subject:  RE: [Sigtran] Comment on M2PA - Slow Start
>
>
>
>
> Sandeep,
> --- [email-masked] wrote:
> >
> >
> >
> > Hi Tolga,
> >
> > In SCTP flow control (both cwnd and rwnd related)
> > procedures are applicable only
> > to User Data. Heartbeat Procedure is only applicable
> > to Path/Endpoint failure
> > detection and cwnd and rwnd restriction does not
> > apply at the time of sending
> > heartbeat messages.
> [TOLGA] Although this might be the main purpose of
> heartbeat, the sentence I quoted from the draft just
> speaks of "data". So, I am still not sure. And even if
> heatbeat does not prevent cwnd to shrink, what is the
> reason for this?
> Sandeep >> I would really be surprised if "Data" above includes
> anything other
> than user data. IMO it was always meant to be user Data.
>
> >
> > Moreover successive heartbeat messages are only sent
> > after the hb_interval +
> > RTO, So there can never be the case that heartbeat
> > is sent before RTO. In any
> > case sending heartbeat message has no impact on cwnd
> > value.
> [TOLGA] Where is it written that heartbeat messages
> are only sent after hb_interval + RTO? In RFC2960 8.3.
> it says "A destination transport address is considered
> "idle" if no new chunk which can be used for updating
> path RTT (usually including first transmission DATA,
> INIT, COOKIE ECHO, HEARTBEAT etc.) and no HEARTBEAT
> has been sent to it within the current heartbeat
> period of that address"
>
> Sandeep >> In the same section some paragraphs down
> "On an idle destination address that is allowed to heartbeat, a
> HEARTBEAT chunk
> is RECOMMENDED to be sent once per RTO of that destination
> address plus the
> protocol parameter 'HB.interval' , with  jittering of +/- 50%,
> and exponential
> back-off of the RTO if the previous HEARTBEAT is unanswered. "
[TOLGA] Yes you are right, but it is only "RECOMMENDED", so I assume I can
send HEARTBEAT just with HB.interval. If HEARTBEAT does not prevent cwnd to
shrink I am wondering the reason for this and want to repeat my original
question : What is the difference of heartbeat or user data from congestion
avoidance point of view, if they are sent with the same period?
>
> >
> > Best Regards,
> > -Sandeep
> >
> >
> >
> >
> > "Tolga Asveren" <[email-masked]> on
> > 07/23/2002 07:02:59 PM
> >
> > To:   [email-masked]
> > cc:    (bcc: Sandeep Mahajan/HSS)
> >
> > Subject:  RE: [Sigtran] Comment on M2PA - Slow Start
> >
> >
> >
> >
> > 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
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > > [email-masked]
> > > Sent: Tuesday, July 23, 2002 5:22 AM
> > > To: [email-masked]
> > > Cc: Tolga Asveren; [email-masked]
> > > Subject: Re: [Sigtran] Comment on M2PA - Slow
> > Start
> > >
> > >
> > >
> > >
> > >
> > > 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
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> >
> >
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
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: "Tolga Asveren" <[email-masked]>
Date: Wed, 24 Jul 2002 19:57:02 -0400

Ray,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 7:06 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] I think there might be problems also for multihomed SCTP
associations case. Even if one uses LSP to take the secondary path throught
the slow start (by giving destination address for the secondary path, while
sending the message to SCTP), if heartbeat does not prevent cwnd to shrink,
in case of path failure, it is possible to start with a cwnd of 2*MTU
(unless it is continued to send LSP from the secondary path)

---

From: Tom George <[email-masked]>
Date: Thu, 25 Jul 2002 13:02:23 -0500

There is already a mention of slow start in the alignment section. I
think it would be a good idea to add a warning about slow start during
changeover. 

If Tolga is right about the multihoming case, then maybe what is needed
is a general warning about slow start, instead of several warnings
throughout the document. Perhaps something like this: Slow start can
cause problems when traffic is initially placed on a link. This would
include link activation (after alignment) and changeover. Furthermore,
multihomed associations can experience slow start when a path fails and
traffic is changed to a different path.

Opinions?

tomG.

> > From: [email-masked] [mailto:[email-masked]]
  [...]
> (unless it is continued to send LSP from the secondary path)
  [...]

-- 
* 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: "Tolga Asveren" <[email-masked]>
Date: Fri, 26 Jul 2002 18:44:46 -0400

Tom,

> Tom George
> Sent: Thursday, July 25, 2002 2:02 PM
> Cc: [email-masked]
> Subject: Re: [Sigtran] Comment on M2PA - Slow Start
>
>
[TOLGA]In addition to the three cases you mentioned(alignment, changeover,
path failure) there migth be problems, even when traffic is flowing, if the
volume is changing. I didn't notice this before asking to Tsvwg but SCTP IG
Page 30 says:
" if ((fligthsize + Max.Burst*MTU) < cwnd)
  cwnd = flightsize + Max.Burst*MTU       "
So, I assume we should send messages like FISU (also for non-primary paths).
An alternative would be to have a big Max.Burst value, but for that IMO one
has to has a network, which is overengineered for the real traffic.

In fact, what does it mean exactly "to go through slow start"? I assume we
want to assure that we have a specific amount of bandwith available(?). But
if we "reserve" that bandwith (either by not caring about congestion control
or by sending some dummy messages or by setting  Max.Burst to a large
value), are we really making use of the resource sharing principle of packet
networks?

I assume you don't like the idea that SCTP emulates layer1( that it is a
perfect wire), but then why do we try to go through slow start and increase
cwnd of SCTP? IMO, this corresponds to have a wire with the bandwith of the
desired cwnd. But as i said, if we don't want to see SCTP as the perfect
wire, why not to say that there will be an implementation dependednt
congestion detection mechanism on SCTP? When there is congestion, SCTP can
inform M2PA and if necessary M2PA can inform MTP3.

From my queries in Tsvwg, I failed to understand the difference between
heartbeat and data with the same length and period, from congestion control
point of view. But current situation is, heartbeat does not play a role in
cwnd calculation. Utilizing heartbeat for that purpose could be nice because
some parameters to keep cwnd around a predefined value are dependent on RTO
and flightsize and actual values of those parameters are not known to
SCTP-user. I think, M2PA should somehow know those parameters and generate
dummy messages according to them to preserve a desired cwnd value.