Subject: [Megaco] megaco load balancer

From: Araz. <[email-masked]>
Date: Sun, 21 Oct 2007 18:08:54 +0330

hello all,
By analyzing the Megaco H.248 protocol for design a "Megaco Load Balancer"
for megaco messages flowing toward MGC's, I found that maybe this issue
is of interest for others too.

Tracking that each message and transaction is correlated with which specific
call ,though possible but it seems it needs a considerable overload in
balancer to parse each message downto terminationID's,contextID's and based
on a set of rules on contextID,teminationID and the specific command can
route the message correctly to the right server.
after all,this can't be consider Done since the message contains other
transactions and Contexts which are of no interest for that MGC server and
passing them to that MGC will cause either unnecessary load on stack or
malfunction by creating transaction State Machine for unnecessary ones.
It seems the protocol has not considered the problem of load balancing a
serious one,simply routing all messages from a specific MG or MG's to "One
specific server",neglecting the case where a very high capacity trunking
Gate Way is bombarding the MGC with a lot of messages for different calls
which is not appropriate or even possible to handle all of them in a single
machine,therefor the need for load balancer arises.
Does anybody have any comments on this issue?

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

---

From: Sudhanshu Garg <[email-masked]>
Date: Mon, 22 Oct 2007 20:58:28 +0530

Hi Araz,

Megaco protocol does not restrict you from sending two unrelated 
transactions in a single message however, it is based on one's 
implementation how to keep different transactions in a single message.
An application sending transactions related to different subscribers in 
single message can possibly lead to overheads on peer entity.

However there are multiple ways by which applications can prevent this 
overhead.

eg.
-  Sender may provide only one board's transactions into a single message.
-  Receiver may parse a message upto mid level (eg. till command level) at 
one master board and based on corresponding subscriber it can forward the 
remaining message (command level PDU in the example) to the subscriber 
boards. Remaining message can be decoded at subscriber boards. This will 
actually help in distributed processing scenarios and load balancing.

Regards,
Sudhanshu Garg
Engineering Project Manager
 
A R I C E N T
 
The Presidency Tower - A
351 / 2, Sector 14, M. G. Road
Gurgaon 122001, Haryana, India
 
Main     +91 124. 417.6218
Fax      +91 124.417.6224
Mobile  +91 999.950.0798

"Araz." <[email-masked]> 
10/21/2007 08:08 PM

To
[email-masked]
cc

Subject
[Megaco] megaco load balancer

hello all,
By analyzing the Megaco H.248 protocol for design a "Megaco Load Balancer" 
for megaco messages flowing toward MGC's, I found that maybe this issue is 
of interest for others too.

Tracking that each message and transaction is correlated with which 
specific call ,though possible but it seems it needs a considerable 
overload in balancer to parse each message downto 
terminationID's,contextID's and based on a set of rules on 
contextID,teminationID and the specific command can route the message 
correctly to the right server. 
after all,this can't be consider Done since the message contains other 
transactions and Contexts which are of no interest for that MGC server and 
passing them to that MGC will cause either unnecessary load on stack or 
malfunction by creating transaction State Machine for unnecessary ones. 
It seems the protocol has not considered the problem of load balancing a 
serious one,simply routing all messages from a specific MG or MG's to "One 
specific server",neglecting the case where a very high capacity trunking 
Gate Way is bombarding the MGC with a lot of messages for different calls 
which is not appropriate or even possible to handle all of them in a 
single machine,therefor the need for load balancer arises. 
Does anybody have any comments on this issue?

Best,
araz.

***********************  Aricent-Restricted   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Arash Azarmi." <[email-masked]>
Date: Tue, 23 Oct 2007 10:52:58 +0330

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.

On 10/22/07, Sudhanshu Garg <[email-masked]> wrote:
>  Regards, *Sudhanshu Garg* Engineering Project Manager * * *A R I C E N T*
>   The Presidency Tower - A 351 / 2, Sector 14, M. G. Road Gurgaon 122001,
> Haryana, India   Main     +91 124. 417.6218 Fax      +91 124.417.6224 Mobile
> +91 999.950.0798
>
>
>
>
>  *"Araz." <[email-masked]>*
>
> 10/21/2007 08:08 PM
>   To
> [email-masked]  cc
>
>  Subject
> specific call ,though possible but it seems it needs a considerable overload
> in balancer to parse each message downto terminationID's,contextID's and
> based on a set of rules on contextID,teminationID and the specific command
> can route the message correctly to the right server.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 30 Oct 2007 09:54:42 -0400

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.

> run on loadbalancer shoud be as light as possible.
...

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 30 Oct 2007 18:56:20 +0100

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