Subject: Re: [issue54] correlator in the PL message header

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 23 Jun 2005 00:17:42 -0700

Thanks for the input, Sue.
I believe we have decided to leave the SN as is and add a Correlator as
well to the header. So that should address any such requirements.

Hormuzd

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 9:55 AM
To: Khosravi, Hormuzd M; [email-masked]
Subject: RE: [FORCES] [issue54] correlator in the PL message header

Hormuzd & All:

Just in case this doesn't get covered, sequence number can have other
benefits besides reliable transport.  

The ordering of information at the application layer can enable some
parallelization of functions for the control plane 

Sue

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Khosravi, Hormuzd M
Sent: Sunday, June 12, 2005 3:23 PM
To: [email-masked]
Subject: Re: [FORCES] [issue54] correlator in the PL message header

Jamal,

Do you see a good reason to keep a SN? I don't see one since the TML
provides reliability. If there is another reason, let us
know...otherwise we should get rid of the SN.

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Sunday, June 12, 2005 8:37 AM
To: [email-masked]
Subject: Re: [FORCES] [issue54] correlator in the PL message header

On Sun, 2005-12-06 at 11:00 -0400, Joel M. Halpern wrote:

> But we can not simply treat the sequence number as the correlator.
> 

Agreed.
In the some cases we could - but i think allowing for such polymorphic
behavior is something we may live to regret (it has been trickery-hell
in netlink to ensure backward compatibility because the seq # is used as
a correlator as well) so lets just add a second 32 bit number in the
main header. 

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 24 Jun 2005 08:40:44 -0400

> well to the header. So that should address any such requirements.

I dont know if we have heard from Weiming on this so we can close it?

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Fri, 24 Jun 2005 15:35:05 +0200

I haven't heard much reactions to my last post on the topic, so let me
reformulate it in a shorter way:
- what is currently called SN is in fact used as a Transaction ID. One
can (ab)use it for sequencing a subset of messages (see details in my
previous post)
- for full sequencing capability, a distinct field from Transaction ID
should be introduced.
- in addition, yet another field for higher-level correlation should be
introduced.

So now that we agreed we need (at least) two fields, how shall we call 
them and what meaning/semantic do we give to them ?

field #1: Transaction ID ? 16 bits ?
field #2: Correlator ? 32 bits ?
possibly field #3: true Sequence Number 16-32 bits ?

Regards,
-Robert

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

---

From: Alex Audu <[email-masked]>
Date: Fri, 24 Jun 2005 10:16:48 -0400

Hello Robert,
 
Given that a transaction is a sequence of message or information exchanges treated as a unit
for the purpose of satisfying a request, I am finding a little difficulty in understanding why 
we need a transaction ID in this layer.  And then a correlator?  What is the need for this?
 
Regards,
Alex.

-----Original Message-----
From: Robert Haas <[email-masked]>
To: [email-masked]
Sent: Fri, 24 Jun 2005 15:35:05 +0200
Subject: Re: [issue54] correlator in the PL message header

So now that we agreed we need (at least) two fields, how shall we call them and what meaning/semantic do we give to them ? 

Regards, 
-Robert 

>I dont know if we have heard from Weiming on this so we can close it? 
 
-- Dr. Robert R. Haas

---

From: Weiming Wang <[email-masked]>
Date: Sat, 25 Jun 2005 00:13:48 +0800

Jamal,

Thanks for the mention, whereas I think I'v expressed my opinion in my previous posts. I can live with two fields (SN and correlator) solution, thought I do think one field is enough for our current use for the message sequencing purpose, that is, sequencing of messages without response messages, which already enough for the purpose like redirect message ordering back. One more thing is, for two fields solutions, I suggest to let the correlator field usually have the same value as the SN field, except for response messages, which should have the correlator values as the messages they reply, so as to simplify the correlator value generating.

Thanks,
Weiming