Subject: RE: [Forces-protocol] topic 4c: Common Header

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 4 May 2004 14:41:57 -0700

Weiming,

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

> > Firstly,  on the msg direction indicator in the header, I actually
originally
> > have two thoughts for it.  One is to define CE id and FE id in a
different
> > space, that is, e.g., using a bit in the space head (mst significent
bit) to
> > mark the different space, another is to  put the 1 bit flag along
with the
> > transaction ID, that is, by viewing the ID we then know where the
msg is
> > generated. One more advantage for latter approach is it may supply
some
extra
> > information for FE or CE to trace the transactions,  and may be of
some help
to
> > sth like transaction atomicity?
> >
>
> I am worried of making this too complex. Is this how GRMP did it?
[Weiming]Maybe it has very little to do with atomicity (after I read
Netlink2
again). Actually it was very important in GRMP because GRMP used it as a
signal
to indicate if it is a ACK or Response message. GRMP defined the ACK and
Response msgs that they had the same transaction ID as the msg they
responsed.
Speaking of this, I agree with you that we need to see the transaction
definition more carefully. For instance, we need to decide what does one
trasaction (with same tran. ID) mean? Can we treat a config msg and its
response
msg as in the same transaction?  How about ACK msg then? (may have two
ACKs
here, ACK to config msg and ACK to config response msg) My idea more
tends to
treat all them as in one transaction therefore they all have the same
tran.ID.

[HK] I agree. The Transaction ID or Sequence No. should be the same in
both Request and Response msgs e.g. Config/Config Resp to denote that
they are part of the same transaction. That was the reason for having a
Sequence no to begin with.

Pls see my other email for clarification on Ack/Resp msg.

Thanks
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 04 May 2004 22:43:43 -0400

> Sequence no to begin with.

If you call that 32 bit value a transaction # it may be a little
misleading; example a transaction may take several messages not just one
(Consider a two phase commit transaction where you send several messages
followed by a commit to complete the transaction). 
I think we should define it as a message sequence. 

Next big question (I asked this earlier) how many PL level messages can
we have in flight? If more than one, do we need a windowing syntax in
the common header?

cheers,
jamal