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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 12 Jun 2005 12:20:32 -0700

I agree, this was along the lines of my previous suggestion. I don't see
the reason for having both a sequence number and a correlator....SN
should not be needed by the PL since the TML provides reliability which
guarantees in-order delivery (acc to the definition). Would you agree?

Thanks
Hormuzd

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

Actually, I would prefer to change the name.

A Sequence number should have a different sequential value has I hand 
messages from the PL to the TML.
A correlator should have distinct values for distinct requests, and
replies 
should have the value from the request.
These are not the same property.  They may even be in conflict.

Note that a request originator is capable of remembering the sequence in

which it sends requests.
Thus, for most purposes a correlator will do more than a sequence
number.
What a correlator does not provide is the ability to compare the order
of a 
received even and a received response.  If some TML may disorder things,

that would be lost information.
If that is a big deal, we need two fields.

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

Yours,
Joel

At 11:19 PM 6/11/2005, Khosravi, Hormuzd M wrote:
>Ok, so you're saying we should use the Sequence number as a Correlator.
>If that is the case then we are in agreement, I think. We should update
>the text.
>
>Let me know if I misunderstood you,
>Hormuzd
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Wang,Weiming
>Sent: Saturday, June 11, 2005 8:14 PM
>To: [email-masked]
>Subject: Re: [FORCES] [issue54] correlator in the PL message header
>
>----- Original Message -----
>From: "Khosravi, Hormuzd M" <[email-masked]>
>
>Yes, a Correlator is useful and currently we have been using the
>Sequence number as correlator. I don't see any other use of the
Sequence
>number since reliability is provided by the TML. I think we should
>change Sequence number to correlator in the draft and update the
>description accordingly unless there is some use for a sequence number.
>
>[Weiming] I think it's too early to say the SN is only for correlation.
>currently I don't think we should a hundred percent to rely on TML for
>thinks
>like sequential ordering.   As a safer mode, I still prefer to have it
>as its
>original  name of Sequence Number. Correlating request/reply messages
>should
>only be one of its functions.
>
>thanks,
>Weiming
>
>BTW, issue 47 looks like the same one...we should close one of these
>issues.
>
>regards
>Hormuzd
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Wang,Weiming
>Sent: Friday, June 10, 2005 9:12 AM
>To: [email-masked]
>Subject: Re: [FORCES] [issue54] correlator in the PL message header
>
>Robert,
>
>----- Original Message -----
>From: "Robert Haas" <[email-masked]>
>
>New submission from Robert Haas <[email-masked]>:
>
>Adding a correlator seems useful: response messages can be matched to
>the
>request messages even if pipelining and reordering occurs.
>It seems that some are currently using the sequence number as a
>correlator:
>this can be dangerous, and not suitable for event notifications
messages
>(nothing to correlate with).
>[Weiming] I'm not sure if you mean to use the SN as a correlator is to
>let the
>response have the same SN as the sender.  If so, I cannot follow well
>why it is
>dangerous and not suit for event notifications.  Could you clarify this
>more?
>
>Thanks.
>Weiming
>
>But this introduces the risk of flooding an FE with too many commands
as
>there
>is no windowing mechanism in place (yet).
>
>----------
>category: Technical
>draft: draft-ietf-forces-protocol
>messages: 129
>nosy: rha
>priority: Should fix
>status: No discussion
>title: correlator in the PL message header
>
>___________________________________________________
>Forces issue tracker <[email-masked]>
><http://www.mip4.org/issues/tracker/forces/issue54>
>___________________________________________________

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 13 Jun 2005 11:30:05 +0800

Firstly , I think even if we use it only as a correlator, the number should
sitll not be generated randomly, rather sequencially. Secondly, it therefore
menas we actually doesn't pay too much by introducing the Sequential Number in
while without loosing the correlator function. Thirdly, it maybe too early to
say a SN is not at all useful for the protocol PL level. For this point, I
suppose we should distinguish the idea of the protocol message sequence from the
TML transport sequence a little. I can curretnly see two cases where protocol SN
may make senses to PL thought not to TML:

1. For messages like Packet redirect messages,  transport order of which may not
strictly requred, but the sequence of the redirected packets still make sense to
the applications of the packets.

2. Usually, core PL process runs in a multi-thread mode, in this case, a SN can
act well as a tracker for the process. This can be used at PL-TML interface PL
side as well as the TML side.  This may also be used for CE or FE failover case
like graceful restart.

Cheers,
Weiming

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

Thanks
Hormuzd

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

which it sends requests.

Yours,
Joel

Sequence
messages
as

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jun 2005 07:31:40 -0400

Actually, I would prefer to put as few restrictions as possible on the 
creator of the correlator, so as to allow the most implementation freedom.

Hence, the only MUST would be that a responder MUST put the correlator from 
a request into the response.

It seems like "A requestor SHOULD NOT reuse the correlator from outstanding 
requests for different requests." makes sense.  I would not want to make 
that a MUST.

An receiver MUST NOT apply any semantics to received correlators.

Sequence information is either derivable from the TML or should be in a 
separate field.
Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 13 Jun 2005 09:01:07 -0400

Ok, folks lets put closure to this: so far the stick-finger-in-the-air
answer i am seeing to the question "should we add a correlator field in
the main header in addition to existing sequence number?"

Jamal: 100% yes
Robert: 100% yes
Joel: 65% yes - Joel can we get a boolean from you?
Hormuzd: 100% no
Weiming:Not sure where you stand.

cheers,
jamal