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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 15 Apr 2004 11:19:38 -0700

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 ?

> > 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 ?

> 
> [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 ?
> 

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.

Regards
Hormuzd

_______________________________________________
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:10:18 -0400

On Thu, 2004-04-15 at 14:19, Khosravi, Hormuzd M wrote:
> interconnects. 

Thanks; i just printed them to study them later.

> Do you see TMLs as something more than a layer to

The hard part is the "services" aspect. Transport services includes but
not specific to:
- reliability vs no reliability
- priority
- congestion control 
- encoding of messages
- security
- Link mngmnt, HA
- peripheral things like "obsolete msg x if you are still trying to
retransmit it"

Somehow the PL should be able to tell the TML on how to conduct certain
behaviors.
 
> don't see the value of standardizing them or this team defining them.

Think of just simple things like:
open(), close(), read(), write(), event(), ioctl();
maybe we are taking them for granted for sockets because they are
already well known. Somehow if you replace that socket with a TML
layer, it doesnt mean they dissapear.
I am not insisting on a API; this could be a very simple protocol that
runs over TCP which provides those interfaces. The advantage with a
protocol is that you can have the PL running on a different machine
(and proxies become easy to do).

> standardize the interface. Am I missing something here ?

I think theres possibilities that there will be other people who will
write only the TML (TIPC being an example). If TIPC adhered to some
interface then i should be able to "plug" into my implementation using a
binary from Jon.
I do understand defining such an API/protocol is making things more
complex, i just dont want to look the other way just because of such
a reason.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 16 Apr 2004 16:20:06 -0400

> Thanks; i just printed them to study them later.

Hormuzd, I just looked at RFC 3293 and briefly at 3292 i cant see the
relation to a TML. 
All 3293 does is encapsulate; none of the transport "services" are
really delivered to the GSMP layer.
Should i continue reading or is this pretty much covering it? ;->

cheers,
jamal