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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 24 Nov 2003 12:29:28 -0800

Patrick,

Pls see my comments below...

-----Original Message-----

[chair hat off]

Hormuzd,

Khosravi, Hormuzd M wrote:

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

why you say one? why is it not both?
[HK] The reason to choose one is driven by simplicity and 
interoperability. When you say choose both, you mean certain
control messages from CE-to-FE such as route updates use multicast
and the rest use unicast ? What does this mean in terms of
Interoperable solutions ? What does this complexity buy you ?
It would be better to say either use Unicast or use Multicast
for all control messages. However, from the discussion so far
doesn't seem like multicast can be used efficiently or in all
cases, without using unicast as well.

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

why is it not a master and many slaves?
[HK] Sure, that's a given. Any client-server architecture has
One server and many clients or one master and many slaves.
Does that automatically mean using multicast ? If this was
the case then all client-server architectures would be using
Multicast to improve performance. The claims being made regarding
scalability are analogous to saying that a web-server cannot
handle hundreds of clients and will need multicast to scale.
Even a Linux box with a single P3 processor can easily scale to
Hundreds of web clients. I need not mention some of the high
end servers using multiple processors which can easily handle
Hundreds of thousands or even millions of clients.
Do you agree ?

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

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.
[HK] Sure, I agree. Same as above.

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

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.

[HK] I completely agree, OSPF is very different and is used for 
exchanging information between routing peers. I have seen OSPF
being used as a primary example of a protocol which uses multicast,
and motivating the use of multicast in ForCES based on it.
As you said OSPF is very different and is probably not a good analogy.

However, even if you take OSPF as an example for motivating ForCES,
there are issues with OSPF such as Congestion Control which were
not considered in its initial design but are being discovered after
years of deployment experience. If anything, we can learn from
the experience and wisdom out there and avoid making similar mistakes
in our protocol design.

Regards,
Hormuzd

---

From: Patrick Droz <[email-masked]>
Date: Tue, 25 Nov 2003 11:49:04 +0100

[chair hat off]

Hormuzd,

I think you are still missing something.

> cases, without using unicast as well.

this statement is con correct to my mind. There are certain things
like route updates that go to all the ports. So in this case
you would use multicast. For firewalling rules which in many
case go only to one port you would use multicast. The combination
of both makes the protocol scalable and future proof. The point
about interpretability I don't get. Simplicity is a good objective
but not if it goes with the price of less flexibility and scalability.

> handle hundreds of clients and will need multicast to scale.

what a strange example. Does a Web server send exactly the same
stuff to all its clients. I already stressed in several mails
that ForCES will in many cases run box internal maybe over
Switch or a PCI bus. Most switches I have seen have unicast
and multicast capabilities included so why do you want to
prevent people from making use of this functionality?

> Hundreds of thousands or even millions of clients.

as I said above you are comparing oranges and apples.

> As you said OSPF is very different and is probably not a good analogy.
in the ForCES context OSPF is completely irrelevant and I have
a hard tim why you even mention it here.

> the experience and wisdom out there and avoid making similar mistakes

I think OSPF has nothing at all to do with ForCES. It is used
completely differently in a different environment.

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