Subject: Re: towards consensus: ForCES transport and group addressing

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 25 Nov 2003 11:41:31 -0800

Hi Robert,

I agree with Joel, I think it will be a big mistake to reach a consensus
without answering all the technical issues that have been raised with multicast,
Namely 1) reliability including CC, 2) command bundling, 3) message explosion
at FEs. In order to have a Interoperable solution, these issues have to be
explicitly addressed. (See my email to Patrick)

Although, Security seems less important at the moment, once the draft reaches
The Security Directorate for review, you will realize its importance as well :-)

Just one more thing, in the US we will be having Thanksgiving holidays from
Thursday to Sunday so a lot of folks are on vacation this week. It will be
courteous to wait till next week so that most folks are back at work before 
rushing into any decisions.

regards
Hormuzd
-----Original Message-----
From: Forwarding and Control Element Separation [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, November 25, 2003 10:37 AM
To: [email-masked]
Subject: Re: [FORCES] towards consensus: ForCES transport and group addressing

I see two kinds of problems with this:
1) Given that an FE being design can not ensure where it will be deployed, 
it follows that all FEs (and CEs) would have to support both UDP and TCP / 
SCTP transport.  (I do not believe that "targeted" is a useful or 
meaningful attribute of an FE or a CE.)
2) If we are going to support UDP, we need to specify the retransmission 
(including backoff), flow control, and congestion reaction algorithms.

On a related note, I do not know what it means to say that FEs and CEs MUST 
support group addressing.  This could mean the simple statement that the 
messages must contain higher level target IDs.  It could mean that we must 
have mechanisms to manage the configuration and use of group addresses.  It 
could mean any number of things.

Yours,
Joel M. Halpern

At 05:10 PM 11/25/2003 +0100, you wrote:
>In order to reach a consensus before we are exhausted posting on the list, 
>let me cristallize what could help unlock the situation.
>
>I presume we should be able to reach consensus on sth like (remains to be 
>defined in more detail):
>
>ForCES transport
>---------------------
>a) An FE MUST support UDP (or raw media encapsulation) as ForCES transport 
>if the FE is targeted at the local scope env.
>b) An FE MUST support TCP (or SCTP) as ForCES transport if the FE is 
>targeted at the global scope environment.
>c) An FE MUST support TCP (or SCTP) AND UDP (or raw media encaps.) as 
>ForCES transport if the FE is targeted at both local and global scopes.
>  (the same applies for the CE)
>
>FEs/CEs that support TCP will support UDP as well (I have never seen an IP 
>stack that offers TCP without UDP). Note that this does not prevent from 
>using TCP in the local scope if the FEs and CEs support it. Thus 
>TCP-proponents should be satisfied.
>
>
>In addition, could we reach consensus on sth like:
>
>ForCES group addressing
>------------------------------
>d) FEs and CEs MUST support group addressing in the ForCES protocol.
>
>Nobody is forced to USE such a group addressing (one can stick to unicast 
>ForCES-addressing and TCP transport in all cases). But if one sees that 
>group addressing fits ones needs (and many have voiced it on the list), 
>then one should be able to use it. Ultimately (and this is probably best 
>so), it's the user writing software in the CE who decides what she/he 
>wants to use.
>
>Note that the phrasing in a), b), c), and d) is meant to satisfy 
>interoperability. Not my ego.
>
>I have the impression that a number of participants in this WG, including 
>other protocol draft authors, tend to agree on these items. Who would not 
>agree (and on what) ?
>
>--
>Robert Haas
>IBM Zurich Research Laboratory
>Säumerstrasse 4
>CH-8803 Rüschlikon/Switzerland
>phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 26 Nov 2003 10:54:39 -0800

Hi Avri

Nice to see your email. You hit the nail right on the head!

This thread started last week with Steve's email on the applicability
of multicast to ForCES and asking for neutral opinion on that.
Unfortunately, it has turned into a Netlink2 vs. FACT or any other
protocol
debate. That was Not the intent of Steve's email, neither has it been
the intent of any of the FACT authors. We didn't even respond to any
emails initially for a couple of days so that all views on this topic
can be heard.

I completely agree that Multicast is Not the deciding criteria for
any protocol, at best it is a transport option. This is what most of
the neural folks said as well, it is a good option to have at the
transport level. However, before deciding on using it as an option,
and definitely before Mandating it, we need to think about and
crystallize
the technical details around it. This is what I have been trying to do
and I believe this is what Joel and David are also asking for. Some
of the technical issues include 1) reliability (including CC),
2) command bundling, 3) FE-to-CE communication, 4) security.
Security is probably not as important as the first 3 but still
needs to be addressed. 

Now here is where instead of discussing the technical issues in a
neutral
fashion, its turned into...Netlink2 can do this and provide mechanisms
for that. But I have seen very little specific details on this and the
more we think about specifics the more we will realize that multicast
comes at the cost of a lot of complexity and interoperability issues
and at best can only be an optional transport.

Thanks & Happy Thanksgiving to everyone in the US !
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of avri
Sent: Wednesday, November 26, 2003 3:38 AM
To: [email-masked]
Subject: Re: [FORCES] towards consensus: ForCES transport and group
addressing

hi,

I just came back from a bit of vacation and had the pleasure of reading
through the many messages that compose the multicast thread.  Made for
an exciting couple of hours on a dreary day.

Though the thread baffles me.

- it is as if 2 of the 3 contending protocols are fighting for
supremacy on the subject of multicast support.  With 3 protocols in
contention it is difficult to understand the positioning and posturing.

- I do not understand in what way multicast support is a criteria for
choosing a protocol.  As I understand the requirements it is neither
required not precluded by the requirements.  From the arguments it
seems like there may be cases where it comes in useful, though there
seem to be issues that need to be resolved in other cases.  As one of
those who is not committed to any of the protocols, I don't see it as a
necessary criteria for choosing and believe that it should be optional
whether a protocol uses multicast as long as it meets the other
requirements.  In many ways it seems as though it may be more of an
implementation issue then a protocol selection criteria.

a.