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

From: Tal Anker <[email-masked]>
Date: Mon, 24 Nov 2003 09:02:36 +0200

All,
I do believe that this thread should converge to _some_ result...
I think I remember someone saying he is writing a draft to capture all the issues with multicast and forces...I believe this is a good direction (maybe the draft can also indicate requirements of the forces protocol so that it can later work over [reliable ?] multicast transport...). Why don't we wait for the draft to be available (or is there a time issue here that I am not aware of... - assuming the draft would not take too long ...).
 
- Tal

	-----Original Message----- 
	From: Jamal Hadi Salim [mailto:[email-masked]] 
	Sent: Mon 11/24/2003 6:13 AM 
	To: [email-masked] 
	Cc: 
	Subject: Re: ForCES transport requirements WAS (Re: Support for multicast in the ForCES protocol

	On Sun, 2003-11-23 at 22:37, Khosravi, Hormuzd M wrote:
	> 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.
	
	> 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.
	
	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?
	
	> 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,
	
	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
	> to be fulfilled.
	
	And they are being met.
	
	> 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).
	>
	
	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: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 25 Nov 2003 11:28:45 -0800

Hi Patrick,

Let me try to explain my point again.
Some of the examples I presented below are similar to examples 
that I have heard for multicast support in the past (OSPF).

There are some technical issues with using multicast that
should be flushed out before deciding to use it as a transport option...

1) Reliability including congestion control. I know congestion control
is not a requirement in the local scope but I do believe it is important
and have heard lots of folks including Ads (Alex Zinin) arguing for
this during our Requirements team discussion on reliability.
2) Command bundling and how this can be done efficiently using
multicast.
(Note: sending one message of size 3x is not more efficient than
sending 3 messages of size x. Actually, you will probably spend more
time encapsulating/decapsulating a big message(3x above).)
3) FE responses to CE requests, or FE-to-CE messages being sent
without swamping all FEs with these messages (in case multicast is used)

I will not mention Security since it don't believe that is as important
in the local scope, atleast not as much as the above.

Now, let me try to answer the question of applicability of multicast.
Lets say 90% of ForCES deployment is in the local scope (rack).
Lets say 80% of those backplanes or interconnects in the rack support
multicast.
Assuming about 40% of these systems have several dozens of FEs in which
case
Multicast adds some reasonable value over unicast. (For hundreds of FEs,
the % of systems is going to be less that 10%.)
Now lets say 60% of your configuration information is routing
information
which is same across all FEs.
Finally, only 60% of the time you will Not use "command bundling" when
downloading this information.

If you do the math, it comes to about 90*80*40*60*60 = 10.3% of use
cases
where multicast is applicable and has reasonable value over unicast.
So when you are trying to come up with a tradeoff of complexity,
interoperability issues of adding multicast vs efficiency it provides,
you need
to find the number of use cases where it can be applied, which is around
10%. 

Do you agree ? I will be happy to change these numbers based on real
Market or implementation information,

Regards
Hormuzd