Subject: [Rserpool] Heartbeat question (ASAP draft, section 2.2.7)

From: Phillip Conrad <[email-masked]>
Date: Fri, 04 Apr 2003 15:46:48 -0500

I have a question about the hearbeat between an ENRP server and a PE.

The ASAP draft says:

>2.2.7 ENDPOINT_KEEP_ALIVE message
... (diagram omitted)
>   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.

So I conclude that the purpose of the ASAP level heartbeat is to be a backup
when the transport layer heartbeat can't do the job.

But from what I read in RFC2960 (see excerpts below) it seems as if the upper layer (in this case, ASAP) has a lot of control over the heartbeat.   

So, my question is this: what is the circumstance in which the mechanisms already in RFC2960 aren't sufficient to get the job done?  

We have restricted PE<->NS communication to SCTP, so the answer "what if the transport isn't SCTP" doesn't apply here.    The ASAP draft says that "time outs are too long, or the heartbeat interval isn't short enough".  But neither of those makes sense to me.  If the if timeouts are too long, then sending a data message over the transport connection isn't going to help.. it will experience the same timeout.   And if the heartbeat interval is too short, the capabilities specified in RFC2960 should allow the ASAP entity to change it to the interval that it needs.  

So what am I missing here?

Thanks,
Phill

(RFC2960, around p. 92, 93...)

>The upper layer can optionally initiate the following functions: 
>
>A) Disable heartbeat on a specific destination transport address of a
>      given association,
>
>   B) Change the HB.interval,
>
>   C) Re-enable heartbeat on a specific destination transport address of
>      a given association, and,
>
>   D) Request an on-demand HEARTBEAT on a specific destination transport
>      address of a given association.

Note: There are some mentions of heartbeat in the implementors guide, but I didn't see how any of them would change the capabilities in the list above.

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

---

From: "Aron J. Silverton"<[email-masked]>
Date: Fri, 04 Apr 2003 15:46:13 -0600

> So what am I missing here?

I had assumed that this was an artifact left behind by once supporting 
other transport protocols between PEs and ENRP servers.  I can't think 
of any reason why one would disable SCTP HB and choose to use ASAP HB in 
its place.

I'm with you.

Aron

-- 
Aron J. Silverton
Senior Staff Research Engineer
Motorola Laboratories, Networks and Infrastructure Research
Motorola, Inc.

Telephone: 847-576-8747
Fax: 847-576-3240
mailto: [email-masked]

---

From: "Aron J. Silverton"<[email-masked]>
Date: Fri, 04 Apr 2003 15:46:13 -0600

I'm with you.

Aron

Telephone: 847-576-8747
Fax: 847-576-3240
mailto: [email-masked]

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Apr 2003 17:46:39 -0600

Actually, when SCTP was in user space (i.e., in the MDTP/DDP era), we
only had one unified heartbeat. I think we have a consensus (at least my
understanding) to keep RSERPOOL level heartbeat because SCTP is now most
likely residing in the kernel. The reasoning is that, while SCTP level
heartbeat monitors the end-to-end connectivity between the two SCTP
stacks, it does not necessarily ensure the e2e liveliness of its ULP. We
are consistent in giving this advice to other ULP developers who are
really serious about reliability (such as sigtran UAs, I think they all
have their own connectivity/liveliness checking on top of SCTP
heartbeat).

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 04 Apr 2003 17:46:39 -0600

regards,
-Qiaobing

---

From: Phillip Conrad <[email-masked]>
Date: Sat, 05 Apr 2003 00:24:37 -0500

Qiaobing:
    OK, your explanation below makes sense... but perhaps the text in the ASAP draft section 2.2.7 should be updated to reflect this reasoning, since at least one other person (Aron) reached the same conclusion as me based on the existing text.

Regards,
Phill

At 05:46 PM 4/4/2003 -0600, Qiaobing Xie wrote:
>> > But from what I read in RFC2960 (see excerpts below) it seems as if the 
>upper layer (in this case, ASAP) has a lot of control over the heartbeat.
>> >
>> >
>> > So, my question is this: what is the circumstance in which the 
>mechanisms already in RFC2960 aren't sufficient to get the job done?
>> >
>> > We have restricted PE<->NS communication to SCTP, so the answer "what if 
>the transport isn't SCTP" doesn't apply here.    The ASAP draft says that 
>"time outs are too long, or the heartbeat interval isn't short enough".  But 
>neither of those makes sense to me.  If the if timeouts are too long, then 
>sending a data message over the transport connection isn't going to help.. 
>it will experience the same timeout.   And if the heartbeat interval is too 
>short, the capabilities specified in RFC2960 should allow the ASAP entity to 
>change it to the interval that it needs.
>> >
>> > Note: There are some mentions of heartbeat in the implementors guide, 
>but I didn't see how any of them would change the capabilities in the list 
>above.
>> >

---

From: Phillip Conrad <[email-masked]>
Date: Sat, 05 Apr 2003 00:24:37 -0500

Qiaobing:

Regards,
Phill

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 07 Apr 2003 11:43:31 -0500

Ok, I've noted this in my to-do list.

-Q

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 07 Apr 2003 11:43:31 -0500

-Q