Subject: RE: [Forces-protocol] RE: PL<-->TML:: topic 1

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 20 Apr 2004 19:55:54 -0700

Hi Weiming,

I used Reliability as an example below but that can be easily extended
to other services.

Let me give a more concrete example which we have already discussed in
the past...

For all control messages (message types A-X), the PL will require the
following services from TML...Strict Reliability, Congestion Control,
Security. (Not sure about HA at this point, we need to discuss that
further)

For all data messages (message types Y-Z), the PL will require the
following services from TML... Congestion Control, Security. 

As for TML capability, etc we can push that as part of pre-association
phase (FEM, CEM) or even before that (compile, integration time). I
don't think we should be concerned with that in the PL team.

Hope this helps,

Regards
Hormuzd 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Weiming Wang

I would like to send such a message from the PL level via the TML with
some indication to the TML that this message needs to be delivered
reliably (obviously via TCP in this example). Clearly it is cleaner for
the PL to have no clue that the TPC connection is being used.
2-3 ways i could do it:
1) call a speacial function[1] which is translated by the CE-TML to mean
send via TCP
OR
2) call a generic function[1] with flags turned to say "reliability
needed" and the TML translates this to mean send via TCP.
OR
3) just send the Forces Messages with some of its flags turned on to
mean reliability on and such a message is translated to mean send via
TCP.

#3 may be the API-avoidance scheme.

[HK] Exactly, #3 is what I was explaining in my last email that I just
sent out. (Use fields/flags in the Common Header to correspond to a
transport service e.g. TCP connection in the TML).
I think we are on the same page now, Hopefully this issue is resolved :)

[Weiming] Among the three schemes, I also more appreciate 3), but I just
wonder
if this is all for TML-PL, e.g., what then for congestion control, HA,
etc?
Basically, I think it is only a specific scheme for reliability. I think
we now
can only say that we have approved to use something like
metadata/fields/flags
for reliability control. Moreover, I think the scheme is also quite at
the
abstact level. We then may have to answer more questions as how we then
define
the 'reliability', how we can know the TML support such 'reliability',
and what
then if the TML can not supply enough capability for such 'reliability'?
From
these viepoints, I'm afraid we still need to use mechanisms like TML
capability
and TML attributes so as to properly configure the TML before we can
actually
use such metadata/fields in the protocol messages. I notice that Jamal
seems to
say such TML configuration is better to be left for CEM and FEM. If it
is, then
I think it may libarate our protocol team a lot. So, Hormuzd, what's
your
opinion?

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 22 Apr 2004 14:19:40 +0800

Hi Hormuzd,

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
Hi Weiming,

[Weiming] We may need to consider more cases on this, e.g., even for the same
message type, messages may have different TML requirements, e.g., for evnet
messages,  failure report event should be strictly reliably and timely
transmitted, while things like heartbeat signals actually don't have the
requirements.
[/Weiming]

[Weiming] This is a long lasting question that I think we have not resolved very
well, that is, if we need to go back to pre-association again when some TML
change happens( link failure, CE failure, etc) during the post-assoc., and how
we go back? Or we just let the protocop layer to deal with such change?

Cheers,
Weiming