Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt

From: Alex Audu <[email-masked]>
Date: Wed, 2 Mar 2005 00:31:55 -0500

Hi All,

What is this talk about doing away with TML headers?  Can
someone explain the rational behind this?  How are you going
to encode the TML messages meant for a remote peer in an
interoperable way if you don't have something like a well 
defined, agreed upon message header?

Regards,
Alex.

In a message dated 2/28/2005 12:43:55 PM Eastern Standard Time, Jamal Hadi Salim <[email-masked]> writes:

>Hi Shuchi,
>
>On Mon, 2005-02-28 at 11:48, Chawla, Shuchi wrote:
>> Jamal,
>> 
>> Thanks for the feedback on the draft.  Comments below:
>> 
>> TML Header (or lack thereof)
>> ----------------------------
>> I concur that it would simplify the protocol to not require a TML
>> header.  However, before we make that decision, I think we would want to
>> make sure we have covered ground with respect to all of the
>> communication that may be required between TML peers. 
>
>A reasonable thing to do
>
>>  We had identified
>> 4 messages so far in this version of the draft: 
>
>I am gonna assume TCP - which is in the context of this draft.
>
>> - 2 multicast support related messages
>
>I described the scheme in earlier email in response to Furquan - involve
>the FE Object and have the multicast be a PL/FE Object
>config/subscription issue.
>
>> - 1 heartbeat related message
>
>use TCP KEEPALIVE; 
>
>> - 1 channel closure related message
>
>EOF is returned when a TCP connection is closed
>
>> Of these, the first three have been addressed in some form in these
>> discussions.  As we detail the protocol further, there may be other
>> messages that may come up - so we would need to ensure that all of these
>> messages can either be eliminated or dealt with in some other manner.
>> So, I just feel that this needs some more analysis.
>> 
>
>Refer to what i said above. We are lucky to have implemented along the
>lines of what you propose (refer to the history i gave earlier)- that
>helped shape my views.
>
>> Separate Peer TML Control Channel 
>> ---------------------------------
>> If we do require peer TML communication, in my opinion the use of a
>> separate communication channel for TML messaging is likely to complicate
>> the situation - in effect, this implies the setup/use of a "control
>> channel for a control channel".  I have not thought about all of the
>> implications, but here are some areas that the protocol would likely
>> need to address:
>> - What if one control channel comes up and the other doesn't?
>> - Guaranteeing message sequencing between these two control channels may
>> become more problematic
>> - The TML Layer even with this separate channel needs the ability to
>> handle two types of messages:
>>   o Those with a TML layer header received over the TML-TML
>> control channel
>>   o Those without a TML layer header received over the PL-PL
>> control channel
>
>In context of TCP - I would say kill this peer TML relationship. I
>probably wouldnt say the same for TIPC.
>
>
>> TML Versioning
>> --------------
>> Not having a TML Layer header would imply that the TML Layer does not
>> have a version associated with it.  Is there any other place the TML
>> version may be embedded?  If not, it would imply that changes may not be
>> made to the TML Layer separate from the PL Layer since any change that
>> might impact interoperability or modify the layer's behavior would need
>> to be reflected in the protocol version.  Since there are multiple TMLs
>> that are likely to exist, but a single PL, it would seem prudent that
>> TML changes be versioned independent of the PL Layer.  How would this be
>> achieved?
>> 
>
>I see versioning as useful in the case where you have a shim header.
>Any other case - the versioning is how code is implemented; and if not
>I would say this is a C/FEM config interface issue. If someone wants to
>have CEM<->FEM communication they could do that; i would till think of
>it mostly as a config of the TML. 
>
>> PL Layer knowledge of (Two) Channels
>> ------------------------------------
>> I haven't thought about this deeply, but here are my initial thoughts:
>> As long as the TML Layer is only responsible for "transport" and is not
>> a decision-maker, I think the PL Layer (or someone other than the TML
>> Layer) should have knowledge of the channels being setup.  This will
>> especially be required to handle failure cases.  If the TML Layer is
>> indeed the only entity aware of this, then it seems that in order to
>> deal with failure cases, the TML Layer would need to take charge, and in
>> that case, there may actually be more messaging required between peer
>> TMLs.
>> 
>
>My view is that the PL should only worry about Forces Level messaging
>i.e treat the TML as a black box; a wire if you may. It just sends
>things down and they get to its peers.
>The PL may "boot" the TML - but thats about as much control it has over
>it.
>Remember: in a PL<->TML interface, open() does not necessarily equate to
>a TCP socket open() - it doesnt in our case. It just means you are
>connected to the TML.
>
>> Also, we haven't addressed HA in detail this draft.  I think some of the
>> decisions we make will need to take into account HA requirements - it is
>> hard to architect HA in at a later stage.
>
>I think we are there - whats missing is the details.
>
>Two levels of HA:
>1) Transport - this is where TML is responsible. Its one layer below the
>PL. If a physical link goes down or a socket dies then TML takes
>necessary action to recover. If absolutely no possibility of such
>recovery (eg when a CE or FE dies) then the PL layer needs to be
>involved.
>If you remove the relationship of knowledge of how many transport
>connections actually exist from the PL level - this becomes more a 
>TML module worry and becomes specific to the hardware in which the TCP
>TML was implemented on.
>
>2) a FE or CE PL. connection to the peer level is down. This is the
>responsibility of the PL. If a CE disappears, then its clear the FE 
>needs to kick in the HA rules it has and either choose another CE or 
>hibernate until current one comes back (we discuss a few of these
>schemes in the draft - may need some reviewing).
>This is clearly a PL module worry.
>
>cheers,
>jamal
>

---

From: Patrick Droz <[email-masked]>
Date: Wed, 2 Mar 2005 15:31:53 +0100

Hi Alex,

ForCES itself is already a protocol. Why do you need on
top of it yet another protocol. Having an additional
ship with just type and length makes parsing of ForCES
messages easier. GSMP did exactly this. But do we
additional messages?

Regards,
Patrick

-- 
   Dr. Patrick Droz 			| [email-masked]
   IBM Zurich Research Laboratory 	| http://www.zurich.ibm.com/~dro
   Saumerstrasse 4 			| Tel. +41-1-724-85-25 CH-8803
   Rueschlikon/Switzerland 		| Fax. +41-1-724-85-78