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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 9 Apr 2004 13:10:19 -0700

Hi Jamal,

I have a couple of points on this topic...

I don't believe we need to define APIs between PL and TML, it is true
that we have separated the 2 layers but introducing and standardizing
new interfaces will introduce unwanted complexity and delay in getting
an interoperable protocol out. In any case, any protocol implementation
will consists of both layers working together and cannot operate with
just one. The interfaces between the layers is completely implementation
dependent. What we need is to define specific requirements for the TML
such as...

For Control messages (or messages A-X) we need...1. strict Reliability,
2. Congestion Control, 3. Security

For Data messages (or messages Y-Z) we need...1. Congestion Control, 2.
Security, 3. Reliability is not needed or optional

Another thing which is needed is Protocol Messages which will help
interaction between PL and TML. This is what Weiming is talking about, I
believe. I will send out some text on Protocol Messages which will
hopefully get us started in that direction.

Another point I would like to bring out is that we need to come up with
one or max 2 HA schemes which will make most sense for our protocol. If
we keep adding new schemes and features we will never get to a single
interoperable solution. We need to decide which scheme will work best
for our case. I will send out some specific text in this regard in a
separate email.

regards
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

Weiming,

BTW, this mailing list latency is horrible; not to forget it has
swallowed at least 2 of my messages that i havent sent in the past. This
is not proper for a discussion. Maybe we should look for alternatives.

Greg, can you confirm that you received this message and that the
mailing list logs show it was received?

On Thu, 2004-04-08 at 11:41, [email-masked] wrote:

> > I am with you on this.
> > We definitely need to have an interface between PL and TML. I
realize
> > this may be adding more complexity but it would be necessary if we
have
> > to tell people to write TMLs.
> [Weiming]This maybe also that Hormuzd means for TML requirements, but
I'm 
> afraid they not just requirements, instead they are items that should
be 
> defined explicitly in the Protocol messages. 
> 

Ok, so we may be approaching this from a different angle. I am thinking
there may be some messages which are just local; eg via an API such as
(invoked by PL):

TML_ioctl(fd, USE_HA_MODE2)

You are thinking that infact the PL constructs a message addressed to
the TML which may be terminated localy. It could also be terminated at a
remote TML. Did i understand you correctly?

> > > a) PL controls TML via some TML setup attributes, which may be
from CE to 
> FE via
> > > ForCES protocol or directly inside CE from PL to TML.
> > 
> > I think theres one more view. Each Local PL may instruct its local
TML
> > on certain things. Basically, theres an API/protocol between the PL
and
> > TML; with control being driven by the PL. For generality, a PL may
need
> > to instruct a remote TML. Is this going overboard?
> 
> [Weiming]Not overboard, I think. Actually by using attributes defined
in the 
> protocol, we have implied this control may be from remote, that is,
may from CE 
> to some FE. From your schemes presented last time on the priority for
multi-CEs 
> controlling a FE, 

Ok this validates my earlier point that you are looking at this from a
purely messaging/protocol view. Which is fine with me but needs some
clarity in regards to addressing. 

> I suppose you actually imply the TML control may be via 
> metadata in the protocol messages for remote control. 
> Talking about metadata, after I posted my last email, I have also
noticed that 
> we may need never able to exclude the control from PL to TML via a per
packet 
> metadata, because a broadcast/multicast ID actually acts like this
kind of 
> metadata. But what we need to discuss to find out is what attributes
and 
> metadata we on earch need. I have a basic thought that we may only use
metadata 
> when we are sure attributes are not feasible for a goal, for it seems 
> attributes are more flexible, while some metadata may have to be
defined in the 
> protocol more strictly, but I'm still not sure of this. Do you have
more ideas 
> on how metadata may look like from protocol layer?

I am just thinking actually the metadata is mostly to instruct the TML
on how to deal with the message. Not to be passed to the PL layer. IOW,
you could send a message to TML to be forwarded to one or more FEs but
you want that message to be delivered reliably on some occasions but not
on others. In such a situation you will have something attached to the
message to instruct it to do so. I am thinking probably a TLV.

[..]

> [Weiming]One more important example for per-packet control is 
> broadcast/multicast support.

This one may be tricky. Do you want the PL layer to know about details
of how the message is transmitted? Shouldnt the addressing take care of
it?

cheers,
jamal

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Apr 2004 18:41:04 -0400

Hi Hormuzd,

On Fri, 2004-04-09 at 16:10, Khosravi, Hormuzd M wrote:
> just one. 

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? 

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

[..]

> hopefully get us started in that direction.

Go ahead and do that although i dont think the fundamental difference
between us at this point has to do with how to replace multiple TMLs.
I believe that the TML is a provider of services centred around
transport. As in any such layering there needs to be (hate to use that
evil word) an API between the two. Whether that takes the form of a
protocol is not the issue.

> for our case. I will send out some specific text in this regard in a

It seems to me like more than one scheme could be supported. But i do
agree with you that if it turns out to be a swiss knife it will not be
very useful. 
When you send those emails, please make sure you have the appropriate
subject heading to allow for maximum feedback.

cheers,
jamal