Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 23 Nov 2003 19:37:21 -0800

I don't see why this has to be a religious debate.
No body is saying "unicast is good, multicast is evil"
This should not be the approach for making technical decisions.
Unicast and multicast both have their merits and drawbacks
and we have to select one that best meets our needs.

Unicast has been working well for a long time in client/server,
Master/slave type of environment. Multicast fits well for
Peer-to-peer environment. ForCES is clearly a master/slave
environment, where the CE is the master or controller and 
the FE is the slave or the element being controlled. Hopefully,
there should be no disagreement on this basic idea. In addition,
we have certain reliability and security requirements that need
to be fulfilled.

On the issue of scalability let me try to give an example which
will bring to light the importance of congestion control. OSPF has
been stated as one of the main examples of a protocol which uses 
multicast as one of its transports in multicast enabled networks.
One of the current OSPF WG drafts...
http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt
Talks about recommendations for improving OSPF scalability in large
networks. It specifically recommends prioritization and congestion
avoidance procedures to help improve the scalability. This draft is
not just based on implementation, but also deployment experience by a 
large operator (AT&T).

regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
Sent: Sunday, November 23, 2003 8:01 AM
To: [email-masked]
Subject: Re: [FORCES] ForCES transport requirements WAS (Re: Support for
multicast in the ForCES protocol

Sigh. We are back to square one. We have two religious views based on
our implementation experiences. Ive just spent 10 emails explaining why
i dont think TCP is sufficient by itself and why multicast transport is
useful;-> Ive been on enough threads on usenet and email to wisen up
and know when to stop.[1]
This is the point where reasonable people agree to disagree and end the
discussion. If this was an implementation this is where we fork ;->

cheers,
jamal

PS: Selection of what gets used for transport is a pre-association
config issue not sure what you see as being interoperable with that.

[1]Otherwise you will make me repeat everything i said in the last 10
emails and you will then repeat exactly what you say below. Its a
vicious cycle - you have not changed my views on multicast and neither
have i changed yours.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 23 Nov 2003 23:13:49 -0500

> I don't see why this has to be a religious debate.

It is when you discuss for a long time and reach the same
conclusion you both had when you started.

> and we have to select one that best meets our needs.

Do you think TCP satisfies all the requirements?
Please read my email on this topic before responding. It will be
that religious discussion i am talking about if you dont read the
emails.
BTW, When did we say we have to choose one over the other?
Could they both be supported maybe?
This is a config issue. Noone has ever ruled out unicast. I dont
understand why you are so adamant on ruling out multicast. Let me guess:
could it be because FACT doesnt support it?

> there should be no disagreement on this basic idea. In addition,

Multicast typically has a sender (the CE in this case mostly) and one
or more receivers (the FE in the case of ForCES). The FE could send an
unsolicited event. Whatever terminology you end up calling such
a setup is unimportant.
I am just curious why you are bringing this topic?

> we have certain reliability and security requirements that need

And they are being met.

> not just based on implementation, but also deployment experience by a

Good, we can learn from it. How exactly does this say multicast is bad?
I did search for the word multicast on that draft and it is not
mentioend once. But you are probably refering to it because OSPF uses
multicast - I would say it is a good proof there is something good about
multicast.

cheers,
jamal

---

From: Patrick Droz <[email-masked]>
Date: Mon, 24 Nov 2003 09:45:42 +0100

[chair hat off]

Hormuzd,

> and we have to select one that best meets our needs.

why you say one? why is it not both?

> Peer-to-peer environment. ForCES is clearly a master/slave

why is it not a master and many slaves?

> we have certain reliability and security requirements that need

I agree on this as long as you also mention that we usually will
have a small number of masters but maybe a very large number of
slaves.

> not just based on implementation, but also deployment experience by a 

how can you compare OSPF with ForCES? OSPF is a protocol that is
deployed over many nodes in general. ForCES will be in many cases
just used inside a single box. Could you please elaborate and tell
us what is the relationship between ForCES and OSPF.

> Hormuzd

Regards,
Patrick

-- 
   Dr. Patrick Droz 			| [email-masked]
   IBM Zurich Research Laboratory 	| http://www.zurich.ibm.com/~dro
   Saumerstrasse 4 			| Tel. +41-1-724-85-25 CH-8803
   Rueschlikon/Switzerland 		| Fax. +41-1-724-85-78

---

From: Sandy Pavel <[email-masked]>
Date: Mon, 24 Nov 2003 11:10:34 -0500

I believe I am missing something here.
Wasn't this group supposed to give a generic solution for a protocol
that would be flexible enough to cover all kinds of technologies or
possible practical implementations?
Or, do we only look at what we have experienced so far in our careers
and anything else is either not true, impossible or not worth
considering? ...

Is ForCES supposed to use only TCP/IP over a network? How about those
who would map it (possibly directly) to the proprietary hardware
transport protocol that runs on the switching fabric? I hope I don't
need to give arguments for this case.

As far as I can tell, there are multi-blade architectures that use
switching fabrics that have a dilation factor between 1.2 and 1.6 (the
multiplication factor that gives the switch internal bandwidth based on
the total external aggregate capacity). This would carry both FE-FE and
CE-FE traffic.
It is not hard to see why, cost wise, it would be preferable to have a
switching fabric with 1.2 dilation factor that also provides a multicast
mechanism versus one that has 1.6 dilation factor that allows only for
unicast.  (I am not saying that the 0.4 factor difference would
represent real world multicast overhead for CE-FE communications. But it
can be for both FE-FE plus CE-FE communication. This is an example to
make a point.)

But an even more compelling argument in favour of multicast was brought
by those who mentioned the cost in CPU cycles when it comes to
simulating multicast by unicasts.
Arguments suggesting that these days we have processors that run 'faster
and faster' are good in a science/technology journal for the masses, but
less so in this group.

Just an opinion.
Sandy Pavel

---

From: Alex Audu <[email-masked]>
Date: Mon, 24 Nov 2003 14:13:38 -0600

Hello Sandy,

Surely, as we move forward, we will be wise to draw on our past experiences.

Else we will have missed the great lessons of histroy.

Certainly processors are getting ever more powerful. That is why today, we
are able to pack the power of yesterday's CRAY into a box that sits on a
desktop
and for fraction of the cost. Even more interesting, the incredible gain in
processing
power is driving the idea of peer-to-peer networking to new practically
feasible
levels (as exemplified by likes of  KAZAA).

So, don't under-estimate the power of the processor.

Regards,
Alex.

---

From: Sandy Pavel <[email-masked]>
Date: Mon, 24 Nov 2003 16:15:14 -0500

Thanks for the history lesson :)

From the pages of the same history book we have learned of many,
notorious by now, claims that the power of the processor is enough for
the tasks at hand, for that specific moment in time and forever. And
yet, the demand for more power is here; people have discovered that they
can do so much more when more CPU power is available.

I wonder if we can say that ForCES protocol is future proof since the
power of processor can only increase. If yes, I rest my case. (should I
mention the word 'scalability'?)

Anyway, enough history; lets focus on the technical aspects.

Regards,
Sandy Pavel

P.S. Alex, I hope that my previous message hasn't offended you or anyone
else for that matter. If it has, I apologize.

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Alex Audu
Sent: November 24, 2003 3:14 PM
To: [email-masked]
Subject: Re: ForCES transport requirements WAS (Re: Support for
multicast inthe ForCES protocol

Hello Sandy,

Surely, as we move forward, we will be wise to draw on our past
experiences.

Certainly processors are getting ever more powerful. That is why today,
we
are able to pack the power of yesterday's CRAY into a box that sits on a
desktop
and for fraction of the cost. Even more interesting, the incredible gain
in
processing
power is driving the idea of peer-to-peer networking to new practically
feasible
levels (as exemplified by likes of  KAZAA).

Regards,
Alex.