Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1

From: [email-masked]
Date: Tue, 20 Apr 2004 13:13:51 -0400

Hello All,

Why cannot the capabilities of TML being conveyed to the PL via FEM or CEM. This will
eliminate unnecessary flag operations for each messages. 

Most of the services are valid for one full session. The flag approach is ok, but it is going
to complicate the protocol operation. 

If you see midcom protocol semantics from IETF midcom WG. ForCES PL is almost closer to that.
They have defined the message structure and focused on what needs to be communicated between endpoints. 
How its being transported is independent and what services are required to satisfy the protocol from the transport
is outside. This way the protocol definition and usage becomes simpler.

Regards
Ramg
 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Khosravi,
> Hormuzd M
> Sent: Tuesday, April 20, 2004 12:09 AM
> To: [email-masked]; Weiming Wang
> Cc: [email-masked]
> Subject: [Forces-protocol] RE: PL<-->TML:: topic 1
> 
> 
> Hi Jamal,
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> 
> Lets take an example of CE-PL sending a message that requires 
> a reliable
> delivery; assume we have a UDP and TCP connection in the TML:
> 
> I would like to send such a message from the PL level via the TML with
> some indication to the TML that this message needs to be delivered
> reliably (obviously via TCP in this example). Clearly it is 
> cleaner for
> the PL to have no clue that the TPC connection is being used.
> 2-3 ways i could do it:
> 1) call a speacial function[1] which is translated by the 
> CE-TML to mean
> send via TCP
> OR
> 2) call a generic function[1] with flags turned to say "reliability
> needed" and the TML translates this to mean send via TCP.
> OR
> 3) just send the Forces Messages with some of its flags turned on to
> mean reliability on and such a message is translated to mean send via
> TCP.
> 
> #3 may be the API-avoidance scheme.
> 
> [HK] Exactly, #3 is what I was explaining in my last email that I just
> sent out. (Use fields/flags in the Common Header to correspond to a
> transport service e.g. TCP connection in the TML). 
> 
> I think we are on the same page now, Hopefully this issue is 
> resolved :)
> 
> 
> Regards
> Hormuzd
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 

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

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 20 Apr 2004 20:09:02 -0700

Hi Robert,

-----Original Message-----
From: Robert Haas [mailto:[email-masked]] 

On the reliability example: remember that ForCES-level reliability is 
somewhat orthogonal to transport-level reliability. At the ForCES level,

I want to get an ACK back from a FE to confirm that it could update a 
firewall rule successfully, for instance.

[HK] Sure, ForCES level reliability will be defined using Message Types
at the PL.
For example, a Configuration Response message could be defined to
provide an Ack at PL and also report the status of a Config Request
message.

So if I tag my ForCES message with "reliability enabled", the TML COULD 
choose to send it over TCP, but this is not mandatory, as using TCP 
alone is not going to be sufficient to ensure reliable processing at the

FE. Actually, the TML could choose UDP, as potential retransmissions 
anyay need to be taken care of at the PL level as well.

Or do you have different views ? Please explain.

[HK] I believe we will need Reliability at both the PL and the TML for
certain messages. The PL will define explicit messages such as
Responses/acks for providing PL level reliability. The TML will define
its own way for providing reliability, CC, etc. For example, the IP TML
may choose to use TCP or UDP to provide a certain service. The TIPC TML
will use TIPC for providing certain service. In the PL Team, we don't
need to be concerned about how the service is provided by the TML but
rather define what service the PL needs/requires from the TML.

Hope this provides some clarification,

Regards
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 22 Apr 2004 11:25:39 -0700

Hi Weiming,

My comments inline below...
-----Original Message-----

I used Reliability as an example below but that can be easily extended
to other services.

Let me give a more concrete example which we have already discussed in
the past...

For all control messages (message types A-X), the PL will require the
following services from TML...Strict Reliability, Congestion Control,
Security. (Not sure about HA at this point, we need to discuss that
further)
For all data messages (message types Y-Z), the PL will require the
following services from TML... Congestion Control, Security.

[Weiming] We may need to consider more cases on this, e.g., even for the
same
message type, messages may have different TML requirements, e.g., for
evnet
messages,  failure report event should be strictly reliably and timely
transmitted, while things like heartbeat signals actually don't have the
requirements.
[/Weiming]

[HK] Yes we could define separate requirements for HBs since they have
been separated in the Requirements RFC as well. But I am not sure if
that is a good idea, there were some email exchanges on the ForCES list
between Joel Halpern and some folks, and Joel made some good points. If
you get the chance to refer to those, they were good discussions.

As for TML capability, etc we can push that as part of pre-association
phase (FEM, CEM) or even before that (compile, integration time). I
don't think we should be concerned with that in the PL team.

[Weiming] This is a long lasting question that I think we have not
resolved very
well, that is, if we need to go back to pre-association again when some
TML
change happens( link failure, CE failure, etc) during the post-assoc.,
and how
we go back? Or we just let the protocop layer to deal with such change?

[HK] Events like Link Failure, CE failure will be delivered to the PL
from the TML so I don't think this is an issue. May be I am missing
something here, but seems like we are spending a lot more cycles on TML
discussion than we should be on this team.

---

From: [email-masked]
Date: Mon, 26 Apr 2004 08:53:56 -0400

Hello Robert, Hormuzd,

Comments are inline.

> Sent: Tuesday, April 20, 2004 11:09 PM
> To: Robert Haas
> Cc: [email-masked]; Weiming Wang; [email-masked]
> Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1
> 
> 
> Hi Robert,
> 

Hormuzd you are correct, We have two things one is reliable message delivery (transport level acks) and reliable message execution  at the other endpoint( application (FE or CE endpoint) as acted on the request and request has been serviced).

Forces PL deals with second level, this also implies the first level of relaiblity.  Forces PL can leverage
transport level reliablity if available from TML layer.

Regards
Ramg

---

From: [email-masked]
Date: Mon, 26 Apr 2004 08:58:41 -0400

Hello,

Comments are inline.

> [mailto:[email-masked]]On Behalf Of ext Wang,Weiming
> Sent: Thursday, April 22, 2004 2:20 AM
> To: Khosravi, Hormuzd M; [email-masked]
> Subject: Re: [Forces-protocol] RE: PL<-->TML:: topic 1
> 
> 
> Hi Hormuzd,
> 
> ----- Original Message -----
> From: "Khosravi, Hormuzd M" <[email-masked]>
> Hi Weiming,
> 
> [Weiming] We may need to consider more cases on this, e.g., 
> even for the same
> message type, messages may have different TML requirements, 
> e.g., for evnet

<Ramg>

We need to mandate for what messages relibality is must and for what messages 
it is not a must.  For example certain services TML layer needs to depend upon its
lower layer for triggers etc. HA services. Those we cannot really mandate thro' the 
protocol operations to TML layer.

<Ramg>
\
> [Weiming] This is a long lasting question that I think we 
> have not resolved very
> well, that is, if we need to go back to pre-association again 
> when some TML
> change happens( link failure, CE failure, etc) during the 
> post-assoc., and how

<Ramg>
Yes this is a better approach to push as part of CEM and FEM configuration.
<Ramg>
 
> Cheers,
> Weiming

---

From: [email-masked]
Date: Mon, 26 Apr 2004 09:06:26 -0400

Hello ,

Comments are inline.

> Sent: Thursday, April 22, 2004 2:26 PM
> To: Wang,Weiming; [email-masked]
> even for the

<RamG>

We need to generalize the requirements, if we develope a protocol reqiurements for each messages
then it will be complex.

Since we have to address to some degree of HA and failure notification of remote node etc. We need
a detection mechanism and also a mechanism to report that to other endpoints.  Typically Heart Beat
messages are request/response and are dealt at various levels. 

I think this example is going out of track for me.

<RamG>

> when some

<RamG>

This depends upon what functionality goes inside the TML. Link failure and dead peer
detection requires both cooperation from TML and PL. HA functionality - session switchover
operation requires support from TML. Many of TML configuration are session specific rather
than message specific.
 
Regards
Ramg

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 26 Apr 2004 10:17:46 -0700

Hi Weiming,

We are on the same page now, which is great! See my reply below.

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

I think I understand what you mean now. I believe what you are asking is
that, if there is a CE failure or TCP/UDP connection failure, how does
the TML deal with this...right?
[Weiming] Exactly.

I think the best approach will be to let
the PL control this behavior. If the TML needs to be re-initialized and
restarted after a failure, the PL can appropriately configure/control
the TML...
[Weiming] But how?

I don't think this belongs in the FEM, CEM. With the
handwaving approach, this can be done without explicitly defining any
procedures. However, we should add some text to the draft to explain
this.
[Weiming] Do you have more clear idea how handwaving approach can handle
this?
If it can, I also prefer to choose handwaving approach firstly.

[HK] The beauty of the handwaving approach is that we don't need to
specify the details of how this is handled, just that we need to add
some text to clarify that this should be handled. For example, the PL
draft must specify that the TML may need to be reconfigured when there
is a connection/association failure which may be caused by CE failure,
FE failure or link failure. Also, if there are any Protocol Messages
that we define to handle these scenarios, they should be explicitly
specified. In the actual implementation, the PL may use some api to
reconfigure the TML, however doesn't need to be explicitly defined in
the PL draft.

Hope this helps,

Thanks
Hormuzd