On 12/8/11 8:16 AM, Joegen Baclor wrote:
> On 12/08/2011 06:47 AM, Worley, Dale R (Dale) wrote:
>>> From: Joegen Baclor [jbac...@ezuce.com]
>>>
>>> I am implementing an RLS service that shares load via DNS/SRV records.
>>> Let us say I have 2 RLS servers sharing the load equally for 200
>>> subscribers. In an ideal setting, each would service 100 subscribers
>>> each. In the moment one goes down, subscribers from the other server
>>> spills over to the other server. So at one point all 200 subscribers
>>> are now subscribed to a single server. When the node that went down
>>> previously goes up, I like to be able to bring back load sharing between
>>> the two nodes. There seems to be no obvious mechanism to do this in
>>> SIP. I would appreciate some insights and suggestions.
>> There are at least two approaches. One approach is to have the RLS
>> servers split the load on a request-by-request basis, so that they are
>> jointly the notifyer UA for the subscriptions. This requires that
>> they share all of the subscription state. When a server sends the 200
>> to a subscription-initiating SUBSCRIBE, it inserts a Record-Route
>> containing a DNS name that resolves to both servers. Thus, each
>> SUBSCRIBE within the dialogs goes randomly to either of the servers,
>> and the server that receives the SUBSCRIBE replicates the updated
>> subscription state to the other server. For any NOTIFY to be
>> generated, the servers have to decide which of them is to send it, and
>> update their mutually-held subscription state to record that fact.
>> This would be rather high-overhead to implement.
>>
>> Another approach is to have both servers serve the same data, but any
>> single subscription is terminated on only one server as notifying UA.
>> If one server goes down, when a UA whose subscription is notified by
>> that server decides to re-SUBSCRIBE, it discovers the server is down.
>> The UA reestablishes a new subscription, which goes to the other
>> server. When the down server comes up again, the load is unbalanced.
>> The overloaded server could force some subscriptions to be
>> reestablished by sending "NOTIFY/Subscription-State: terminated". But
>> I don't think there's any point in doing that -- of necessity, either
>> server must be able to handle the full load without degrading the
>> system.
>>
>> Dale
>>
>
> Thanks Dale. I think you do have a good handle on this being the
> author of RLS in sipX. I am actually contemplating on option 1 and
> simply have a static algorithm in the proxy to somehow control the
> balancing based on realtime load of each RLS server. I am indeed
> tempted to resort to simply use the 3265's Notify with state
> "terminated" and hope that the UAC is compliant and re-establish the
> dialog but having to rely on "UAC's" compliance almost always guaranty
> an interoperability issue.
If you are using DNS/SRV load balancing, then simply terminating the
subscription and having the subscriber reissue it is sub-optimal. Since
the load balancing is static, presumably half of the terminated
subscriptions will come back to the server that terminated them. So you
will end up only shifting 25% of the load to the recovered server.
You could do something extreme, like send a REFER/Replaces with
method=SUBSCRIBE, using an address that prefers the server you want to
transfer to. But the likelihood of that being supported by the
subscriber is slim to none.
I'm inclined to agree with Dale thatyou just do nothing, and let it
level out based on attrition.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
