Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA

From: [email-masked]
Date: Fri, 16 Apr 2004 05:08:50 -0400

Hello,

comments are inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Khosravi,
> Hormuzd M
> Sent: Thursday, April 15, 2004 7:05 PM
> To: [email-masked]
> Subject: FW: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA
> 
> 
> Resending since I received an error.
> 
> -----Original Message-----
> From: Khosravi, Hormuzd M 
> Sent: Thursday, April 15, 2004 11:20 AM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA
> 
> 
> Jamal,
> 
> Thanks for your comments...my replies below.
> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> > True on introducing more complexities - not sure i agree on the
> > "unwanted" part. Maybe this is something that we need to decide on
> first
> > before moving forward. Do we wanna say it that Forces can 
> work only on
> > the spefic TMLs? 
> > 
> > [HK] No we don't, but that doesn't mean we need to define and
> > standardize an API. Look at GSMP for example, it doesn't 
> define an API
> > but can still function on multiple TMLs. Why cant we use a similar
> > approach ?
> 
> Any particular GSMP RFCs/drafts? 
> [HK] See RFC 3292, RFC 3293. The 1st is the protocol and the second is
> the TML approach, i.e. encapsulations defined for different
> interconnects. Do you see TMLs as something more than a layer to
> abstract interconnect details and provides certain services to the PL
> above ?

<RamG>

Sounds like a good approach to me. We can reuse those mechanism in specifying the 
TML requrirements.
 
<RamG>

> 
> > > The interfaces between the layers is completely implementation
> > > dependent. 
> > 
> > I think it may be beyond "implementation" specific now that we have
> > decided to go TMLs, no? I still would like our customers to 
> use their
> > own TMLs as long as they provide "services" to the PL layer for the
> > items you mention: reliability, congestion control, 
> security, HA etc.
> > Infact in their own private environment i would like to care less if
> > they present those services to the PL layer or not. Seems to me like
> > this would provide greater spread for Forces.
> > 
> > I believe we need to decide on this issue before moving forward.
> > 
> > [HK] Sure your customers can use their own TMLs, infact that is the
> > idea. But as you said, what is important are the services or
> > requirements for TMLs such as reliability, etc.
> > 

> Right, but exposing the abilities of the TML to meet the 
> desires of the
> the PL needs an interface defined.
> 
> [HK] In some cases, yes you need and interface...but there can be
> implementations which don't have a clean interface. I am not 
> opposed to
> APIs or interfaces, infact we have them in our implementation...but I
> don't see the value of standardizing them or this team defining them.
> The reason for separating the PL and TML was 2 fold, 1. to allow fast
> progress on both in parallel, 2. to allow defining multiple TMLs for
> different interconnects. If we start defining interfaces, my fear is
> that we defeat the 1st reason. Also, unless you think that separate
> vendors will be implementing TMLs and PLs, there is no need to
> standardize the interface. Am I missing something here ?
> 

<RamG>

Instead of defining the TML layer API if we specify the required functioanlity what is expected 
from PL that's a good starting point.  Defining API's may make sense if more there are many potential
applciations going to use the TML directly, current ForCES PL is the one which has this requiements.

One clarification ... because its confsuing from the emails...
  
If we are going to define the API for TML layer(top half), then ForCES message structure what we have 
been discussing becomes the part of the TML layer (bottom half). Then ForceS PL layer (bottom half)becomes implementation
specific all it has to do is invoke those TML (top half) API's. Then it becomes the repsonsibility of the TML bottom half
to transform those API data strcuture into the ForCES message format...  

<RamG>
 
> > 
> > [HK] Sure the layering will need an API in some implementations, but
> we
> > don't need to define those APIs. Lets leave this to the vendors who
> > implement the protocol. In any case, do you really think we can
> > standardize APIs in the IETF ?
> > 

<RamG>
This if just background information not required for this discussion -  we have socket API's draft from IETF and If I remember correctly IETF has specified API's as part or along with FTP protocol other than that i don't know any thing out of 
my memory.

But socket API is different when compared to TML and PL interface. For TCP and SCTP mutiple types of applications needs 
to interact. Where as in our case for TML only PL is the current application.

May be in the appendix or some other document we can provide examples of common adaptation case.

<RamG>
 
> We need to define an interface that TMLs can attach to (or looked at
> from the other side PLs can attach to). 
> Whether its a protocol between TML and PL(TCP would be fine 
> to me) or an
> API is not as important - the important piece is an agreement 
> that such
> an interface is needed to begin with.
> I dont think the IETF is adverse to standardizing on some sane APIs
> when it is sensible; example:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt
> 
> [HK] Sure, it makes sense in case of SCTP sockets...I really 
> don't think
> its needed in our case....What do others think on this issue ??
> 
> I think its important to resolve this issue to move forward.

<RamG>

As mentioned earlier..

SCTP and TCP has wide application usage, there is clealy companies involved in providing stack and companies involved in
developing applications. 

Where as in TML and PL case, the requirements are ForCES specifics, no applications other than ForCES have 
such requirements. IMHO, if we specify only the requirements and leave the adaptation (implemenation open) will be a good
idea. 

Let us take a simple example of IP itself it can run over "Foo" , The foo can be any layer  but it is the responsiblity of the Foo to define the adaptaion of IP and it is not in the scope of IP.  

If this is ok, to move forward we can first define the TML requirments. If there is a strong emphasis then we should consider for API. But IMHO the API may not be needed.

<Ramg>

Regards
Ramg

> 
> 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: Jamal Hadi Salim <[email-masked]>
Date: 16 Apr 2004 11:40:45 -0400

> applciations going to use the TML directly, current ForCES PL is the one which has this requiements.

Note, could be an API or protocol (Refer to my last email to Hormuzd 
on this). There could also be more than one PL using the same TML.
I agree with you a good starting point is defining what services
are to be provided by the TML to the PL.
Clearly, the most important one is transport and all its aspects.
Also clear that the PL should have a say in the degree on how those
services are provided. Again, this is valuable if you are able to
request at a per packet level.
>From an API perspective (could easily be mapped to a simple protocol
over TCP for example), i see:

=>open(): connects a PL to a TML
=> close(): disengages PL from TML
=> read(): PL reading from TML
=> write(): PL writting to TML
=> event(): dont want to talk about poll/select() - TML notifying PL
=> ioctl(): PL controlling something within a TML (eg you could fit both
a bind() and connect() like call here, also things like a "move"
operation from PL->TML etc).

> to transform those API data strcuture into the ForCES message format...  

Yes, i think it becomes a blackbox how the TML does things. There may
be some things where it may be more of grey than black box; example is
what you mention above on encoding where the possibilities I see are:

1) raw mode: TML creates and fills all the headers
2) medium mode: PL creates the headers and partially fills some headers.
TML adds the rest of the headers. 
3) cooked mode: PL is responsible for headers

[..]

> <RamG>
> 
> As mentioned earlier..
> 
> SCTP and TCP has wide application usage, there is clealy companies 
> involved in providing stack and companies involved in
> developing applications. 
> 
> such requirements. IMHO, if we specify only the requirements and leave 
> the adaptation (implemenation open) will be a good
> idea. 

I think we need some minimal interface; however i havent looked at the
GSMP RFCs maybe theres something clever there.
True that this will add one more twist, but i am not sure how to avoid
it.

cheers,
jamal