Subject: RE: [Forces-protocol] HB msgs ?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 16 May 2004 19:59:57 -0700

Weiming,

You make a good point. I was just thinking 2 msgs for HB, HB
Resp/Ack...4 msgs will be a bit too much. Anyways I am not religious
about this one, neither is Jamal, I think. We are just stating our
preferences.

Lets see what Avri prefers. I am fine with whatever the majority
decides.

Regards
Hormuzd
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Weiming Wang

[Weiming] One more thing we should note is, we have totally only arround
10
message types for our protocol, to have another 2 to 4 msgs specifically
for HB
looks really  biased and makes it more or less ugly in the appearance of
our
protocol.
I even more prefer to the scheme to treat HB as an LFB (I remember Jamal
mentioned this), than to have separate msgs for them.
[/Weiming]

I guess the key question that I would ask is if we want Event msg to
symbolize asynchronous events or we want to mix the semantics with
synchronous msgs as well ? I think keeping the 2 separate is cleaner,
but I am open to other views as well.
[Weiming] I don't think we may need to distinguish semantically the syn.
and
asyn. msgs in our protocol, because they have no principal difference in
our
scope.  We can say an event notification is asyncronous, but we can also
say any
query or config from CE to FE is also asyncronous. Actually I just think
it
makes little sense to distinguish them.

Avri, could you share your opinion on this ?

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

---

From: [email-masked]
Date: Mon, 17 May 2004 14:10:48 +0200

On 17 maj 2004, at 04.59, Khosravi, Hormuzd M wrote:

> I was just thinking 2 msgs for HB, HB
> Resp/Ack...

i am not sure I understand why a HB needs an ack as everyone should be 
sending them on a similar interval  (though in some network 
environments, hopefully not synchronized)

a.

---

From: Robert Haas <[email-masked]>
Date: Mon, 17 May 2004 18:08:59 +0200

All,
We should assess the tradeoff for HB (and potentially other 
protocol-specific messages) being treated as:

a) an Event (of a meta LFB representing the FE),
 or
b) as its own specific Message Type (i.e., in the Common Header).

To me, the most important is that:

a) has a cleaner unified design: protocol-specific messages such as HB 
are treated as LFB messages, but

b) has a simpler parsing when doing traffic analysis: protocol-specific 
messages are easier to spot in the flow of LFB messages: no need to look 
into the body of the message to find out that it is a HB.

Anyone has other arguments in favor of one or the other ? Let's then 
judge which one is more suitable.

-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Weiming Wang" <[email-masked]>
Date: Tue, 18 May 2004 10:23:54 +0800

Hi all,

I quite agree to assess the HB msg.  To do this, I think we may need to assess
the importance of HB first.  My thought is, although HB is a very good mechanism
for detecting aliveness of elements, it is only one of the ways for the purpose.
I cannot see any reason the HB should be as a MUST item in our protocol. Note
that, HB consumes quite a lot resourses, while sometimes customers may prefer to
use something like a simple query instead of the HB to see the aliveness of
elements, especially when the system is short of resourses. As a result, HB
should be able to be started or stopped by our protocol freely, that is, the
operation to be able to subscribe/unsubscribe an HB should not be missed in our
protocol (I suppose Jamal also proposed this idea).  This also means that if we
use specific msgs for HBs, we surely need more than two msgs (HB, HB
config(including sub/unsub), HB response).

One more thing is, HB should be very flexible to use, e.g., its interval should
be flexible to be changed on the fly. In this way, system may be able to adjust
the interval according to its current resourse state, so as to slow down the HB
if the resourse is not enough. Anyway, HB acts more like a supplimentary tool
instead as a vital one during the system running.

I noticed Jamal and Robert have mentioned the effectiveness for HB msg.  Yes, I
agree a precise HB format is much better, because number of HB msgs will be
huge.  After comparing the two possible format, I just found that using a HB
event msg for HB may only consume 32bit more and one step more parse, compared
with a specific HB msg. Therefore, I still prefer to use HB as event.

Cheers,
Weiming

----- Original Message -----
From: "Robert Haas" <[email-masked]>

All,

a) an Event (of a meta LFB representing the FE),  or
b) as its own specific Message Type (i.e., in the Common Header).

-Robert

Khosravi, Hormuzd M wrote:

>[Weiming] One more thing we should note is, we have totally only arround 10
>message types for our protocol, to have another 2 to 4 msgs specifically for HB
>looks really  biased and makes it more or less ugly in the appearance of our
>protocol.
>[Weiming] I don't think we may need to distinguish semantically the syn. and
>asyn. msgs in our protocol, because they have no principal difference in our
>scope.  We can say an event notification is asyncronous, but we can also say
any
>query or config from CE to FE is also asyncronous. Actually I just think it