Subject: RE: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 6 May 2004 19:16:29 -0700

Weiming,

-----Original Message-----
>
> Association Setup, Setup Resp msg
> Association Teardown msg
[HK] I agree with the general concept of setup, setup Resp, teardown (I
think we all do) and don't want to fight over names or bits either. I
will make a simple technical point...we have reserved 8 bits for Msg
Type which means we can define 256 Msgs, so why not use this ? It will
be much easier & efficient for someone implementing the protocol to look
at the Msg type field and say if it is a Asso Setup msg, Teardown msg or
Setup Resp...rather than parsing the Msg type field and then some flags
and then coming to the same conclusion. Do you guys agree ??

[Weiming] Hormuzd, what you said really confused me. This was exactly my
idea. I
mentioned this many times before. But at that time, seemed you as well
as Jamal
objected it , which made me actually give it up completely. I think now
we have
come to a compromise to use more sythisized msg type mode.  Why should
we try to
break this compromise again?  If you now realize we can make full use of
the msg
type field, then I would like to pick something more for discussion,
because I
think many of them have much meaning than just 'setup' teardown'.
[/Weiming]

[HK] I think you have misunderstood some of my arguments. I would like
to use the bits in the Msg Type field as much as possible for describing
messages rather than using it in conjunction with some other fields. At
the same time, I don't think we need too many messages. Also, I think
our main argument was around using FE/CE prefix for messages... Jamal,
others & myself see that as limiting the scope of some messages such as
Join, leave, etc to a certain extent. Does that make sense ? Hope this
clarifies your confusion.

So the big question is how do we proceed forward ?? :-) We have couple
of options...
One is to use the compromise list that I sent out (as you can clearly
see, Jamal agrees with having a Subscribe msg)
-OR-
We can go with the approach that I have described below using Msg type,
Msg sub-type (4 bits each)....
May be we can have some middle ground like 4 bits for Msg Type, 4 bits
for Msg Sub-type such that...Msg Type = Association & Subtype = Setup or
Teardown or Setup Resp. This might be easier to implement/parse and also
use the bits more efficiently.

Think about this and let us know ? I don't want us to keep spending so
many cycles discussing Msg names when we all agree on what kinds of
msgs/functionality we need...

Here is the summary of what we need...
Setup, setup resp, teardown
Query, query resp
Config, config resp
Subscribe, subscribe resp, unsubscribe, unsubscribe resp
State maintenance, state maintenance resp 
Event Notification
Packet redirection
Heart beat, HB resp (Its better to keep this separate from Event msg as
Jamal suggested)

We can arrange this as either Msg Types or Msg Type/subtype, let us know
what you like ?
Also, if adding FE/CE prefixes to some of these messages such as Setup,
makes you happy, I am fine with that :) I want us to make fast progress
on this and not get stuck on names. But pls take into account all the
discussions that we have had so far on peering, msgs, etc.

Sorry about the confusion before, but hope this helps clarify stuff,

regards
Hormuzd

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

---

From: "Weiming Wang" <[email-masked]>
Date: Fri, 7 May 2004 13:33:08 +0800

Hormuzd,

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>

Weiming,

-----Original Message-----

[Weiming] Hormuzd, what you said really confused me. This was exactly my idea. I
mentioned this many times before. But at that time, seemed you as well as Jamal
objected it , which made me actually give it up completely. I think now we have
come to a compromise to use more sythisized msg type mode.  Why should we try to
break this compromise again?  If you now realize we can make full use of the msg
type field, then I would like to pick something more for discussion, because I
think many of them have much meaning than just 'setup' teardown'.
[/Weiming]

[HK] I think you have misunderstood some of my arguments. I would like
to use the bits in the Msg Type field as much as possible for describing
messages rather than using it in conjunction with some other fields. At
the same time, I don't think we need too many messages.

[WeimingRe] I'm afraid there is a little contradiction here with your idea. To
make more use of MsgType field is to have more messages, rights? My original
idea was to use the field more fully.  E.g., I would prefer to distinguish msgs
such as config, query, and event msgs between the LFB config, event, and query
from others, because I'm sure the msgs for LFB operations are quite different
from others like FE coarse layer operations (as Robert proposed for FE LFB or I
proposed for FE slave). This LFB difference is much bigger than the difference
of association 'Setup' and 'Teardown'. My idea is If we have decided to use
flags in msg body to describe the former difference, we have no reason not to
use the msg body flag for the latter description, unless you can present other
reasons that the 'setup' and 'teardown' MUST be two msgs other than that the Msg
type field is enough.
[/Weiming]

Also, I think

[WeimingRe] Prefix itself makes no sense.  The arguments behind it is I think
for some messages,  the FE->CE and the CE->FE are quite different, therefore we
may need two messages for the purpose. For some other msgs, we can only
currently define one direction operation, such as the query msg, config msg,
capability msg (if we have).  Therefore, I think our main difference is if we
should use more messages or not and if we need to use more clear names for the
msgs or not. My confusion with your idea is that,  it seems sometimes you like
using less msgs and more synthisizied msg names, but sometimes especially in
some I think very tiny cases, you seem like using more msgs and verbose msg
names.  I just think a good protocol may need to be more uniform and consistent
even by the appearance.
[/Weiming]

[WeimingRe] Actually I don't see any differences between the two schemes you
proposed,  I don't think it is me who have slowed down the progress in this
point :)  What I just want to know is the reasonable reason (other than making
more use of MsgType) why you don't agree the following two schemes, instead to
use more complex scheme:

1. to use flags in the msg body to describe the operation of 'setup/resp'
'teardown'.  I think Jamal more inclide to this also.
2. to use flags or an FE attribute to describe subscribing/unsubscribing events.
I think Jamal more means the subscribe function is important.
[/WeimingRe]

We can arrange this as either Msg Types or Msg Type/subtype, let us know
what you like ?
Also, if adding FE/CE prefixes to some of these messages such as Setup,
makes you happy, I am fine with that :)

[WeimingRe] Not actually. If you'd like to have the Prefix to make me happy, pls
add some for msgs like query, config:).  I actually don't care if using FE setup
or not, because I have seriously considered your idea that we may need to setup
CE in the future.

I want us to make fast progress
on this and not get stuck on names. But pls take into account all the
discussions that we have had so far on peering, msgs, etc.

[WeimingRe] I think I have already given up pushing the prefix for the purpose
of our fast progress. I'm not sure why you mention this here again. Do you think
it is still the barrier?
[/WeimingRe]

Cheers,
Weiming