Subject: Re: Section 9: Heartbeat Messages

From: Dong Ligang <[email-masked]>
Date: Wed, 7 Sep 2005 21:48:24 -0400

hi, 

First, I think b) should be followed, as we do it in our implementation and 
others.

Besides, I agree with either of the following two options.

<draft-ietf-forces-protocol-05>
Heartbeat Message never expect responses.
Message Transfer Direction: CE<->FE
CE and FE passively detect the liveness of the peer.

<jamal>
Heartbeat Message can expect responses.
Message Transfer Direction: CE<->FE
FE passively detect the liveness of CE
CE actively detect the liveness of FE by requesting ACK

regards
Ligang

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 08, 2005 1:57 AM
Subject: Section 9: Heartbeat Messages

> Folks,
> 
> At the moment we are ambiguous about the heartbeat; the draft states
> as it being either from CE->FE or FE->CE and in-fact doesn't discount
> CE<->CE or FE<->FE (which is outside the scope).
> 
> a) What we have found is that the most effective way to do this is to
> actually have heartbeats going from CE->FE since the CE is the master,
> mostly. More importantly is that this is allows for more complexity on
> the CE than on the FE (which is important). I also like the fact that 
> if we ever use a multicast capable TML, we can optimize further the
> amount of traffic on the wire - which is impossible if direction was
> FE->CE.
> 
> b) We have implemented the thought originated from Joel to have the
> heartbeats being optimized (for scalability purposes) to be adaptively
> traffic-sensitive. In such a scheme heartbeats are only sent if no other
> traffic has been sent to the FE since the last heartbeat interval. This
> is a good optimization since it means that in idle (CE->FE) periods a
> lot more heartbeats are sent than in busy periods.
> 
> c) Further observation is that the directionality is important. If
> CE->FE is the direction, all this is doing is health checking from the
> FEs perspective of the CE. Vice-versa if direction was FE->CE.
> Ideally we would like both health checks. So one thing we are
> experimenting with is an extension of #b above. 
> Instead of just the check for whether we have sent any traffic to the FE
> in the last heartbeat interval, we also check if we have received any.
> In most cases if we sent, we probably also received a response, so the
> check doesnt make a difference. In the cases where we have not received
> traffic from the FE, we set the ACK flag which tells the FE to actually
> respond to the HB. Only in this case do we have bidirectional HB, i.e, a
> ping-pong.
> 
> Could people please express their opinions on this? interop will be
> affected if any one implementation doesnt obey _all_ 3 rules above.
> I think all 3 above are very useful and if theres agreement i will edit
> the draft to reflect things.
> The FE Protocol Object LFB will have to change, but lets not go there
> yet - lets agree on the above first.
> 
> cheers,
> jamal