Chronological Thread 

< Chronological >      < Thread >

---

Dear all,
see my comments below.
Best regards
Michael
On Friday, Jan 24, 2003, at 04:43 Europe/Berlin, Thomas Dreibholz wrote:

On Thu, 23 Jan 2003, Tuexen Michael wrote:

Hi Tibo,

see my comments below.

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN CP SE C 7 e-mail:
Michael.Tuexen AT siemens.com

-----Original Message-----
From: thibault Renier
[mailto:toubix AT kom.auc.dk]
Sent: Thursday, January 23, 2003 1:23 PM
To: Tuexen Michael;
rsplib-discussion AT sctp.de
Subject: Re: [RSPlib-Discusssion] heartbeat mechanism implementation


Hi Michael,

the ASAP draft refers to the 'endpoint keep alive message'
which is just, in
my opinion, another way to name a heartbeat mechanism :

That is correct.

2.2.7 ENDPOINT_KEEP_ALIVE message
This message is sent to a PE by the ENRP server has a
"health" check.
If the transport level Heart Beat mechanism is
insufficient (usually
this means that time outs are set for too long or
heartbeats are not
frequent enough), this adds heartbeat messages with the goal of
determining health status in a more timely fashion.


Let summarize like this:
1_ there is a HB mechanism implemented at the SCTP layer,
between the PU and
the PE

This is true for SCTP based channels. But if the service
is UDP based, you do not have this. This is just transport
layer supervision, whatever the transport layer does.

2_ another 'HB mechanism' exists between the PE and the NS,
implemented in
RSerPool
Am I right ??

The PE<->NS communication MUST use SCTP. Therefore you have
SCTP Heartbeats. The Heartbeat Timer is per SCTP default 30 sec.
but can be configured by the SCTP ULP, ASAP for example.
The ENDPOINT_KEEP_ALIVE message is send by the ENRP server.
You can change the timeout in rsplib/nameserver.c. It is up to
you to configure it. Keep in mind, using the ENDPOINT_KEEP_ALIVE
messages can make sure that the primary path never becomes idle,
all other paths will be supervised by the SCTP mechanism.

The ASAP keepalive mechanism also ensures that the application (above
layer 4) is still alive. The kernel could still answer to SCTP heartbeats
while
the application is deadlocked etc..

Thomas is correct here, but I have doubts that it works like this.
Normally you code the HB stuff, it is simple and very good tested. I made
the experience that the protocol engine can be totally screwed up, nothing
is really working but the HB stuff does. The hope is, that assuming SCTP
is in the kernel and the user in userland, the user will crash. This will
free the sockets and the SCTP peer will detect this. So I'm not convinced that
the application level HBs are of much use if you have transport level HBs.

so,
have you only implemented the SCTP HB mechanism,

No, both are implemented.

how are(is) these(this) mechanism(s) implemented,

Using timers.

what is the frequency for message sending,

Depends on the timers which can be changed.

do you have an idea of the overhead introduced by these mechanisms,

You need the bandwidth of the messages and the CPU time at the ENRP
server if you have a lot of PEs.

what's your opinion concerning their efficiency ?

Everything depends on the application. Ymus must have the requirements
of the application and see how you can fullfill them with the timers here.
Problably I would prefer adopting the SCTP Heartbeat Timer to fullfill
my application requirements instead of using the ASAP mechanism.

Best regards
Tibo


----- Original Message -----
From: "Tuexen Michael"
<michael.tuexen AT siemens.com>
To: "'thibault Renier'"
<toubix AT kom.auc.dk>;
<rsplib-discussion AT sctp.de>
Sent: Wednesday, January 22, 2003 5:36 PM
Subject: RE: [RSPlib-Discusssion] heartbeat mechanism implementation

Hi Tibo,

what HB mechnism are you talking about? We use SCTP as the transport
layer protocol. It has Heartbeats. The Heartbeat timer is a
parameter of the SCTP implementation.

There is no notion of Heartbeat Message in ASAP or ENRP.

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN CP SE C 7 e-mail:
Michael.Tuexen AT siemens.com
-----Original Message-----
From: thibault Renier
[mailto:toubix AT kom.auc.dk]
Sent: Wednesday, January 22, 2003 5:20 PM
To:
rsplib-discussion AT sctp.de
Subject: [RSPlib-Discusssion] heartbeat mechanism implementation


Hi,

I am wondering how you implemented the heartbeat mechanism in your

RSerPool version. Here are some points I have in mind :

- on which principles (push, pull) have you based the

implementation of
this feature,

- is there a heartbeat mechanism only between the PUs and the PEs,
- is this implemented only at the SCTP layer,
- what is the frequency of the messages sent and what is

the overhead
introduced,

- what do you think about the efficiency of the heartbeat

mechanism(s)
implemented, could an implementation of an heartbeat
mechanism at the SIP
layer (running on top of RSerPool) be a solution to potential
problems when
implemented at the RSerPool (SCTP) layer ?

Thank you.

Regards
Tibo
_______________________________________________
rsplib-discussion mailing list
rsplib-discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/rsplib-discussion

_______________________________________________
rsplib-discussion mailing list
rsplib-discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/rsplib-discussion

_______________________________________________
rsplib-discussion mailing list
rsplib-discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/rsplib-discussion

---

• [RSPlib-Discusssion] heartbeat mechanism implementation, thibault Renier, 01/22/2003
  • <Possible follow-up(s)>
  • RE: [RSPlib-Discusssion] heartbeat mechanism implementation, Tuexen Michael, 01/22/2003
    • Re: [RSPlib-Discusssion] heartbeat mechanism implementation, thibault Renier, 01/23/2003
  • RE: [RSPlib-Discusssion] heartbeat mechanism implementation, Tuexen Michael, 01/23/2003
    • RE: [RSPlib-Discusssion] heartbeat mechanism implementation, Thomas Dreibholz, 01/24/2003
      • Re: [RSPlib-Discusssion] heartbeat mechanism implementation, Michael Tüxen, 01/24/2003

---

Archive powered by MHonArc 2.6.19+.