Subject: RE: [Forces-protocol] Issue 0: Application addressing

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 10 Mar 2004 17:03:48 -0800

Jamal,

I think we are in agreement about the FE ID portion of the addressing
and what it identifies (an FE instance). It also looks like everyone is
in agreement that a LFBID and LFBInstanceID are also needed for the
protocol. Where there appears to be disagreement is whether the LFBID
and LFBInstanceID belong in the common header or in the TLV.

I believe, like many others that LFB-related IDs (LFBID and
LFBInstanceID) belong in the TLV and not the common header. The primary
reason is to allow one message to affect more than one LFB. This is more
reasonably handled in the TLV. 

If we are in agreement that the LFBID and LFBInstanceID are part of the
TLV, it seems like Issue 0 can be closed. Do others agree?

Regards,
Ellen

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Wednesday, March 10, 2004 4:47 PM
To: Deleganes, Ellen M
Cc: [email-masked]; [email-masked]
Subject: RE: [Forces-protocol] Issue 0: Application addressing

On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote:
> So if you have a proxy that is "fronting" for multiple FEs, what does
> the ID contain? 

I would think there would be a unique ID for each FE being addressed.
Protocol doesnt care who is handling it; 

> If it is the ID of the proxy, how does the proxy know
> which FE to configure? 
> I think even in this case the ID should identify
> the FE so the proxy knows which FE the CE wishes to configure.

Exactly. So message goes say to IP X which is a proxy; but destination
ID refers uniquely to the FE.

>  If this
> is the case FE ID seems to be appropriate nomenclature. 

So far we seem to be saying the address looks like:

ID:=FEID: LFBID: LFBInstanceID

So you are refering to that one portion of the ID i hope?
in which case we may have no issues. 

> How the message gets to the proxy should be transparent to the ForCES
> protocol. 

It is.

> This can be handled by correctly addressing the message (or
> putting into the right socket or whatever) at the underlying transport
> the proxy ID should not have to be part of the ForCES protocol. 

It is not. Nothing in the Forces header helps identify it as a proxy.

cheers,
jamal

_______________________________________________
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: 10 Mar 2004 21:26:31 -0500

Ellen,

> reasonably handled in the TLV. 

I had a small related discussion with Weiming on this and i asked for
that to be deffered to later on; Let me repeat some bits of that
discussion for clarity.

I may be biased by the way we did things in netlink2;  
In netlink2 we batched several messages in one TCP or UDP PDU. 
In other words to send to x netlink2 messages you would
have the following:
L2hdr:IPhder:TCP/UDPhdr:Forcesmsg1:Forcesmsg2...ForcesMsgx
(and you make sure you dont exceed the MTU)

1) The overhead in terms of processing is better with putting the LFBID
within the main header because parsing of fixed headers is faster than
that of TLVs.

2) Theres a space (bit-abuse) threshold where it becomes valuable to
move the LFBid inside the body as a TLV.
A 16 bit representing a LFBid will end up taking 64 bits (if you assume
16 bits for Type and 16 for length).
So for a small batch of messages it is more valuable to put the LFBID
in the main header; for a large number it is valuable to use
the TLV space.
The breakeven point for UDP is around 5 batched messages . Around 7 for
TCP and lower for running directly over ethernet.

So we may have to weight out the options and come to some conclusion.

My opinion is we should probably allow both schemes - however i am 
not religious. I would like to hear what my other coauthors have to say
on the topic before we close it.

> TLV, it seems like Issue 0 can be closed. Do others agree?

Refer to above.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 21:54:41 -0500

I should have mentioned the work done by Guillame Goutaudier was very
helpful for us in understanding batching better. Thanks Guillame.

Reference is at:
Goutaudier, G., "Enhancements and Prototype Implementation
              of the ForCES Netlink2 Protocol, IBM Research Report
              RZ3482", September 2003, <http://domino.watson.ibm.com/
              library/cyberdig.nsf/
              papers?SearchView&Query=(goutaudier)>.

I think we can move on past issue 0. I would like my Netlink2 coauthors
to comment - unfortunately they are all either tied up with customers
or travelling at the moment.
In any case, we can move on and revist later; i think the issue is
now resolvable.

cheers,
jamal

---

From: [email-masked]
Date: Thu, 11 Mar 2004 12:59:46 +0900

> on the topic before we close it.

I think think allowing both my represent an interoperability problem.

a.