Re: TML events

Hi Ellen,

Thanks for the comments and they are all reasonable. I'v begun to update the draft to try to relfect recent comments from the list.

Weiming
----- Original Message ----- 
From: "Deleganes, Ellen M" <[email protected]>
Subject: Re: TML events


Hi Weiming,

I don't think anyone is arguing that a description of the semantic
behavior of event notification. What they (and I) object to is
prescribing a specific implementation.

In particular, prescribing how asynchronous events should be handled to
the level of detail seems out of the scope of the IETF. It seems
reasonable to point the issues out that you've outlined as informational
text, but defining the implementation details of how events pass from
the TML to PL should be left to the implementer. Do we really believe
different vendors will have to interoperate at the PL/TML boundary? To
say that the PL definition is generic enough to work across different
TML implementations is different than expecting all implementations from
various vendors to interoperate. If the latter is expected, then a
different forum (interoperability group) is needed to hammer out the
APIs, but that isn't the IETF.

The semantic description can include requirements such as whether events
are asynchronous or synchronous, an implementation must avoid deadlock,
a failure of a TML thread should not take out the whole system, etc.

Regards,
Ellen Deleganes 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Wang,Weiming
Sent: Thursday, August 10, 2006 10:09 PM
To: [email protected]
Subject: Re: TML events

Hi Joel,

I think you'v well summarized the key point we are addressing. It seems
Alex and Huaiyuan all tend to the same idea you propsed. 

Now my question is, if we only give  the definition of events types and
a related attribute for PL able to subscribe/unsubscribe the events,
while leaving the way the event notivication to users, to my thought,
there will then be no interoperability. Remember that we required a PL
implementation can traverse any types of TMLs implementations.  

It seems we come back to the point on how we can achieve
interoperability while abandoned API like details.

Thanks,
Weiming

----- Original Message ----- 
From: "Joel M. Halpern" <[email protected]>
Subject: Re: TML events (was Re: TML Service Primitives)


> The TML service primitives need to define what the events 
> are.  Different implementations may choose different mechanisms to 
> pass asynchronous notifications.  We are not attempting to define an 
> API here (I hope).  Our focus is a semantic interface that different 
> TML protocols must meet and that the PL can count on being provided.
> 
> Yours,
> Joel M. Halpern
> 
> At 11:42 AM 8/10/2006, Wang,Weiming wrote:
> >Hi Huaiyuan,
> >
> >Thank you so much for the valuable comments.
> >
> >  I agree that it is an issue worthy more discussion how asyncronous 
> > events should be  passed from TML to PL. As you pointed out, 
> > current TML SP adopts callback mechanism for asyncronous events 
> > passing between PL and TML. If we could find a better way than the 
> > callback, that would be very valuable.
> >
> >It may be ture callback may lead to the problem that TML and PL must 
> >be the same process for one same event type, hence may lead to some 
> >sharing  problems for the system compared with a modularized system.
> >
> >Whereas I have to point out that the problem you saw may exist for 
> >all TML service primitives rather than only for the events callback. 
> >It may just because of  the nature of service primitves. A service 
> >primitve acts more as a way for layering a system rather than to 
> >modularize the system. If we want to get a modularity, an 
> >interprocess communication way may be much better, which is usually 
> >based on messaging protocols, but this may not fit for communication 
> >between TML and PL.
> >
> >In the current scheme for TML events, we use TML configure operation 
> >to subscribe or unsubscribe TML events. For example, for ForCES 
> >message receiving mode, if  we subscribe the TMLMsgArrivalEvent, the 
> >ForCES message receiving is in asyncronous mode, otherwize, if we 
> >just use TMLreceive primitve for ForCES message receiving, it is in 
> >syncronous mode. Hence, we may not in the need of a specific 
> >primitive for set of async/sync operation mode selection.
> >
> >Could you give more ideas on how a socket API may better resolve the 
> >same process problem?
> >
> >Thanks a lot for the comment.
> >
> >Weiming
> >
> >----- Original Message -----
> >From: Michael
> >To: [email protected] ; [email protected]
> >Cc: [email protected]
> >Sent: Thursday, August 10, 2006 3:17 PM
> >Subject: Re: TML Service Primitives
> >
> >
> >Hi, Weiming & Alex,
> >
> >
> >We believe that the definition of asynchronous event 
> >"callbackTMLMsgArrivalEvent()" given in a callback form is fine.
> >
> >This asynchronous event works fine under some circumstances, 
> >especially when the intended communication traffic is low, sporadic 
> >and communications should take place in a timely fashion.  However 
> >it bears some shortcomings under some other circumstances when the 
> >communication traffic is heavy.
> >
> >Current carrier-level routers normally have FIB (Forwarding 
> >Information Base) in CE, which is responsible for routing 
> >downloading, refreshing and aging periodically, and the data traffic 
> >is normally heavy. In this case, if, once there is a packet coming 
> >from peer TML every time, a callback function will be invoked, in 
> >order to make this kind of callback function work, TML and its upper 
> >layer like PL must work as separate threads in a process. Otherwise, 
> >upper layer like PL can not see any content of message processed by 
> >this callback function. Since they share the same process space, 
> >once TML thread crashes, it will lead to the failure of the whole 
> >process with high possibility. Here we should harness the natural 
> >protection provided by separate process spaces, that is, it is 
> >better for TML and PL to work as different processes. In addition, 
> >multiple threads in a process will share the global data structure, 
> >mutual exclusion or synchronization mechanism will be required, 
> >which might block theads in PL layer, in some situation, this is not 
> >expected to take palce. If mutual exclusion or synchronization is 
> >not handled properly, deadlock would happen, high availability is 
> >not guaranteed.
> >
> >Another shortcoming of callback mechanism is that this kind of 
> >callback functions will execute different processing according to 
> >the type of each message, there are many different paths inside it, 
> >its frame in the stack would be large. When it is called every time, 
> >a large memory is allocated in stack for it, but only some path is 
> >executed, a lot of memory is wasted, swapping operation on the stack 
> >will take much time also every time.
> >
> >According to the above reasons, another asynchronous mechanism 
> >rather than callback function is required. We can borrrow some ideas 
> >from socket API, a primitive "SetOperationMode(Async/Aync, 
> >MessageQueueName)" is called before any other primitives defined in 
> >the draft is called to indicate asynchronous/synchronous mode is 
> >preferred. Of course, all other primitives must implement different 
> >modes inside them.
> >
> >
> >Best Regards
> >
> >Huaiyuan,Ma
> >&
> >Zengjie, Kou
> >
> >
> >----- Original Message -----
> >From: Michael
> >To: [email protected]
> >Sent: Wednesday, August 09, 2006 7:05 PM
> >Subject: Re: TML Service Primitives
> >
> >
> >Hi, everyone,
> >
> >Besides that asynchronous event should be considered, it may be 
> >necessary for us to define the asynchronous version
> >of TML primitives like TMLSend(), TMLReceive() etc. We can achieve 
> >this feature by providing one more parameter in their
> >formal parameter list, alternatively, we can specify this mode 
> >(asynchronous mode) by such command like ioctl().
> >
> >This requirement is from the efficiency, as we know, although the 
> >synchronous message passing is simple for programming, however,
> >it may cause the process to sleep while holding the resources it is 
> >assigned to when no message is available, once a message is
available.
> >it will be waked up.
> >
> >But, although asynchronous message passing is a little bit complex 
> >for code, but its performance is high.
> >
> >In a word, we may have to consider the asynchronous message passing 
> >primitives.
> >
> >
> >Kind Regards,
> >
> >Huaiyuan,Ma
> >
> >----- Original Message -----
> >From: Alex Audu
> >To: [email protected]
> >Sent: Wednesday, August 09, 2006 9:11 AM
> >Subject: Re: TML Service Primitives
> >
> >
> >Hi weiming,
> >
> >The model seems to be fine,..i.e.  Capabilities:- what the TML can 
> >do, Attributes:- what properties of
> >the TML can be configured,..and Events:- what happens in the TML, 
> >some of which it may need to
> >communicate to the user or upper layer.
> >
> >The TML service primitives therefore should provide ways to:
> >  (1) access or utilize the capabilities,
> >  (2) configure the attributes,
> >  (3) access or utilize the events.
> >
> >Currently, what you have in the service primitives list enable item 
> >(1) above (i.e. read, write, etc), and also
> >item (2) Configuration of attributes.  You are missing the 
> >asynchronous signals or events group (item (3)).
> >For example, how does the TML inform the upper layer that data has 
> >arrived from the peer? So you may
> >need a DataArrived primitive.  Other key asynchronous events should 
> >also be accounted for (e.g. errors,
> >link outage,..etc.)
> >
> >
> >Cheers,
> >Alex.
> >www.garlandsoftworx.com
> >
> >
> >-----Original Message-----
> >From: [email protected]
> >To: [email protected]
> >Sent: Mon, 7 Aug 2006 2:04 AM
> >Subject: TML Service Primitives
> >
> >
> >Hi all,
> >
> >I'm going to update the TML Service Primitve draft. The current
version is  at
> >http://www.ietf.org/internet-drafts/draft-hadi-forces-tmlsp-00.txt .
> >
> >I'm trying to post key ideas of the draft in followed posts to try 
> >to raise some
> >discussion on it. Please be generous to show your comments. Thanks!
> >
> >The basic structure for TML SP is as below:
> >
> >1. The TML is modelled with three kinds of properties:
> >     TML events
> >     TML attributes
> >     TML capabilities
> >( I'l give the TML events, attributes, and capabilities defined in 
> >current draft
> >in other emails)
> >
> >2. The properties are described in XML.
> >
> >3.  The following TML Service Primitives are defined:
> >      TML Open
> >      TML close
> >      TML Configuration
> >      TML Query
> >      TML send
> >      TML receive
> >( I'l give the individual definitions of the SP in other emails)
> >
> >The first point for discussion is on the feasibility  of the given
basic
> >structure of TML SP.
> >
> >Could you show your opinions?
> >
> >Thanks,
> >Weiming
> >
> >
> >
> >Check out AOL.com today. Breaking news, video search, pictures, 
> >email and IM. All on demand. Always Free.