Subject: RE: [Megaco] megaco load balancer

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 2 Nov 2007 11:46:09 +0100

>However I think H.248 and megaco message structure is not suited for
heavy load balancing.

Load balancing for distributed processing of protocol endpoints
(layer/stacks) is a rather old study item.
I don't want to start a discussion on this, because this is mainly
implementation specific, related primarily to data locality, realtime
responsiveness and redundancy group concepts in distributed processing
environments.
 
I'm interested in your requirements for a protocol design which should
support LB?
Guess that should be first clarified before evaluating any client/server
or master/slave protocol (like H.248).
 
Could you provide your requirements list?
 
Thanks,
Albrecht 

________________________________

	From: Araz, [mailto:[email-masked]] 
	Sent: Freitag, 2. November 2007 09:43
	To: Schwarz Albrecht
	Cc: [email-masked]
	Subject: Re: [Megaco] megaco load balancer

	Dear Mr.Albrecht,
	Thanks for the hint.Actually I have studied the LB_CA algorithm
throughly but I'm not easy with it as a good solution.
	I have just a general view of SCTP and haven't studied SCTP
throughly I have to check it out see what will provide us. 
	However I think H.248 and megaco message structure is not suited
for heavy load balancing.
	regards,
	Arash.

	On 10/30/07, Schwarz Albrecht <
[email-masked]> wrote: 

		Arash,
		
		you are considering a load balancing/load distribution
algorithm taking
		into account information elements from H.248 Messages in
my
		understanding:
		
		LB_CA = f(information from H.248 Message level) 
		
		The LB algorithm is acting on H.248 Control Association
(CA) level as
		far as I understand.
		Agreed that such an LB would require some kind of "deep
message
		inspection" (DMI).
		
		Alternatively, - dependent on H.248 transport mode -,
might be other
		balancing/distribution capabilities already on H.248
transport
		connection level.
		This is e.g. discussed by COM16-D229-E "H.248.4
GCP-over-SCTP (3)
		(Further Discussion)" for SCTP-based transport. 
		Id est, you could think about an algorithm, just looking
at information
		elements on SCTP Association (SA) level:
		
		LB_SA = f(information from SCTP Association level)
		
		Such an approach may drastically simplify the "load
balancing" problem. 
		Of course, this implies a correspondent support of a
dedicated "SCTP
		multi-stream mode" support.
		This is feasible for a number of possible "H.248 to SCTP
Stream" mapping
		functions.
		
		Conclusion:
		H.248-over-SCTP, together with particular SCTP
multi-stream mode
		support, may provide very effective means concerning
load balancing
		support on the H.248 receiver side.
		
		-Albrecht
		
		PS
		There are a number of contributions arround D229. 

		> -----Original Message-----
		> From: Tom Taylor [mailto:[email-masked]]
		> Sent: Dienstag, 30. Oktober 2007 14:55
		> To: Arash Azarmi.
		> Cc: [email-masked]
		> Subject: Re: [Megaco] megaco load balancer
		>
		> The only Megaco mechanism that would support what you
want is
		> the virtual MG concept. I know that's the wrong
direction on 
		> the face of it, but at least it allows separate
associations
		> between partitions of an MG and different MGCs. The
catch is
		> that this would be static rather than dynamic, unless
you had
		> some sophisticated management system reassigning
terminations 
		> to different virtual MGs from time to time. That would
		> probably require a reset of the control association.
		>
		> Arash Azarmi. wrote:
		> > Hello there,
		> > that's the exact source of problem of the overhead.I
have
		> no info of
		> > others policy and how they manage to compose
messages out of
		> > transactions and one message and transaction does
not
		> belong to only one Call.
		> > So as you mentioned one have to parse the
message(which because of 
		> > megaco message grammar it's a heavy thing) at a
master board or
		> > loadbalancer to find out which server each command
belongs.
		> and after
		> > that compose new messages for every MGC out of
"every 
		> single message"
		> > it had recieved.Quiteheavy for a
loadbalancer,inconsistent with the
		> > principle that the processes run on loadbalancer
shoud be
		> as light as
		> > possible. 
		> > Best,
		> > Arash Azarmi.
		> >
		> ...
		>
		> _______________________________________________
		> Megaco mailing list
		> [email-masked] 
		> https://www1.ietf.org/mailman/listinfo/megaco
		>

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Araz," <[email-masked]>
Date: Fri, 2 Nov 2007 00:49:20 -0800

Dear Mr.Taylor ,
Thank you very much this might be a good point to start I have to analyze it
more.
Best,
Arash

On 10/30/07, Tom Taylor <[email-masked]> wrote:
>
> The only Megaco mechanism that would support what you want is the virtual
> MG
> concept. I know that's the wrong direction on the face of it, but at least
> it
> allows separate associations between partitions of an MG and different
> MGCs. The
> catch is that this would be static rather than dynamic, unless you had
> some
> sophisticated management system reassigning terminations to different
> virtual
> MGs from time to time. That would probably require a reset of the control
> association.
>
> Arash Azarmi. wrote:
> > Hello there,
> > that's the exact source of problem of the overhead.I have no info of
> others
> > policy and how they manage to compose messages out of transactions and
> one
> > message and transaction does not belong to only one Call.
> > So as you mentioned one have to parse the message(which because of
> megaco
> > message grammar it's a heavy thing) at a master board or loadbalancer to
> > find out which server each command belongs. and after that compose new
> > messages for every MGC out of "every single message" it had
> > recieved.Quite heavy for a loadbalancer,inconsistent with the principle
> > that the processes
> > run on loadbalancer shoud be as light as possible.
> > Best,
> > Arash Azarmi.
> >
> ...
>

---

From: "Araz," <[email-masked]>
Date: Fri, 2 Nov 2007 00:42:45 -0800

Dear Mr.Albrecht,
Thanks for the hint.Actually I have studied the LB_CA algorithm throughly
but I'm not easy with it as a good solution.
I have just a general view of SCTP and haven't studied SCTP throughly I have
to check it out see what will provide us.
However I think H.248 and megaco message structure is not suited for heavy
load balancing.
regards,
Arash.

On 10/30/07, Schwarz Albrecht <[email-masked]> wrote:
>
> Arash,
>
> you are considering a load balancing/load distribution algorithm taking
> into account information elements from H.248 Messages in my
> understanding:
>
> The LB algorithm is acting on H.248 Control Association (CA) level as
> far as I understand.
> Agreed that such an LB would require some kind of "deep message
> inspection" (DMI).
>
> Alternatively, - dependent on H.248 transport mode -, might be other
> balancing/distribution capabilities already on H.248 transport
> connection level.
> This is e.g. discussed by COM16-D229-E "H.248.4 GCP-over-SCTP (3)
> Id est, you could think about an algorithm, just looking at information
> Such an approach may drastically simplify the "load balancing" problem.
> Of course, this implies a correspondent support of a dedicated "SCTP
> This is feasible for a number of possible "H.248 to SCTP Stream" mapping
> functions.
>
> Conclusion:
> H.248-over-SCTP, together with particular SCTP multi-stream mode
> support, may provide very effective means concerning load balancing
> > The only Megaco mechanism that would support what you want is
> > the virtual MG concept. I know that's the wrong direction on
> > the face of it, but at least it allows separate associations
> > between partitions of an MG and different MGCs. The catch is
> > that this would be static rather than dynamic, unless you had
> > some sophisticated management system reassigning terminations
> > > others policy and how they manage to compose messages out of
> > > transactions and one message and transaction does not
> > belong to only one Call.
> > > megaco message grammar it's a heavy thing) at a master board or
> > > loadbalancer to find out which server each command belongs.
> > and after
> > > that compose new messages for every MGC out of "every
> > single message"
> > > it had recieved.Quiteheavy for a loadbalancer,inconsistent with the
> > > principle that the processes run on loadbalancer shoud be
> > as light as
> > > possible.
> > > Best,
> > > Arash Azarmi.
> > >
> > ...
> >

---

From: "Araz," <[email-masked]>
Date: Sat, 3 Nov 2007 15:32:24 +0330

Surely you're right.I'm not argueing on Megaco protocol procedures and
concepts they are very fine and well designed. The only thing I have comment
on is as I clarified the Megaco Message Structure,because of the followings
:

1- MEGACO does not restrict every message responsible for only one call(by
call I mean a context and the terminations involved in it.).So in general
it's possible that one sends a message which contains several transactions
each containg different calls ,each call processed in a differnt machine.(I
know this may happen rarely in one's implementaion ,but the point is its not
restricted explicitly.So you have to count it on your ,for example,load
balancer algorithm and design.)

2- The message text encoding grammer is nested and finding out a specific
value will require you to parse the entire message.Comparing for example to
SIP which the message grammer is linear.This will also influence message
encodeing/decoding .

3- At last I think it could be a good idea that in every message,beside the
mID which shows who is sending the message,we also assign a space for the
reciever address.
This may be usefull if messages are passing from a proxy in the middle.

Best,
Arash.

On 11/2/07, Schwarz Albrecht <[email-masked]> wrote:
>  ------------------------------
> *From:* Araz, [mailto:[email-masked]]
> *Sent:* Freitag, 2. November 2007 09:43
> *To:* Schwarz Albrecht
> *Cc:* [email-masked]
> *Subject:* Re: [Megaco] megaco load balancer
>
>
>  Dear Mr.Albrecht,
> I have just a general view of SCTP and haven't studied SCTP throughly I
> have to check it out see what will provide us.
> On 10/30/07, Schwarz Albrecht < [email-masked]> wrote:
> >
> > Arash,
> >

---

From: "Araz," <[email-masked]>
Date: Mon, 5 Nov 2007 11:19:55 +0330

Thank you very much.Would you please guide me through one more question ?
In my design of Megaco LoadBalancer , I decide to pass each transaction in a
message to one machine(Stack+Call Control Application.) based on the fact
that each transaction will "Logically" contain Action's related to only "one
Call". So no one will put actions for different contexts,or Calls,in same
Transaction since it's not logical and transaction is not a Transport
mechanism, is for grouping related commands for being execute serially.
I am in doubt if I've interpreted the H.248 for the above consideration
truely.
Best,
Arash.

On 11/5/07, Tom Taylor <[email-masked]> wrote:
>
> Yes, that's right.
>
> Araz, wrote:
> > I looked thru the H.248 V3 part on virtual MGs (11.1) .I face a question
> > which although maybe clear from context but I want to ask to be sure of
> it :
> >
> > Each virtual MG has its own separate mID ?for example a Physical MG may
> be
> > partitioned to 2 virtual MG's with miDs like : IP:Port#1 and IP:Port#2
> and
> > each will create associations with their own MGC's ?
> > Thanks ahead,
> > Arash.
> >
> >
> >>> recieved.Quiteheavy for a loadbalancer,inconsistent with the principle
> >>> that the processes