Subject: RE: [Sipping] Overload/Congestion mechanisms - design choicesandissues

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 28 Jun 2006 15:25:35 -0400

Jeroen,

Load balancing is what you do to avoid any one node in the system from
becoming overloaded.

Overload control is what you do when load balancing has failed.

There is a degree of system-wide (or subsystem) visibility that may be
needed to address this problem, unfortunately, upstream servers may be
left to learn this through trial and error.  The current capacity of a
node could be considered state.  Changes in that state could be thought
of as events.  We do have event reporting mechanisms in SIP.  However,
that may require a degree of cooperation in what is both implemented and
used for a system-wide mechanism to work.  And a key problem is what do
you do when some upstream node doesn't cooperate?

Two cents from the peanut gallery,
Mike

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Wednesday, June 28, 2006 3:11 AM
> To: Volker Hilt; Jonathan Rosenberg (jdrosen)
> Cc: IETF Sipping List
> Subject: Re: [Sipping] Overload/Congestion mechanisms - 
> design choicesandissues
> 
> Volker, Jonathan,
> 
> "load balancing" and "overload control" are two related but 
> different issues. I get the feeling that we need to get the 
> distinction clear before plunging into this discussion. I 
> don't pretend to know the answers, but let me try and give it a go
> 
> "Load balancing" is about resource optimization and 
> scaleability. What makes load balancing for SIP (or proxy 
> systems in general) difficult, is that behind a SIP element 
> there is typically a cloud of other systems. An upstream SIP 
> peer typically has no knowledge of the structure of this 
> cloud, especially when it is in another domain. My hunch is 
> that to enable a peer to make good load balancing decisions, 
> it will need load information that is not only based on its 
> direct next hop but also on the systems behind that. 
> So a major issue (for load balancing) is the propagation and 
> aggregation of this information (and the underlying model).
> 
> "Overload/congestion control" is about reducing the load on a 
> particular system that is getting more than it is capable of 
> handling. The two mechanisms that can be applied here are 
> traffic diversion and throttling. To decide that overload 
> control is needed, information from a single element (ie the 
> system that is experiencing overload) suffices. However, to 
> enable good diversion/throttling decisions, you may need the 
> same information that is used for load balancing.
> I wager that the upstream system does not need to know 
> exactly which part of the peer system (disk, network, etc) is 
> experiencing overload. This information would be useful for 
> diagnosis, but not to decide what (ie divert and/or throttle) 
> to do. Since the system under overload would know best what 
> effect certain decisions would have on its overload status 
> (and perhaps also on the rest of its network), I reckon that 
> the system under overload should make a suggestion to the 
> upstream peer on what to do. In other words, not "help, I am 
> 98% loaded, and it is because my disks are failing" but 
> concrete suggestions / parameters on what to do (see next).
> 
> Regarding traffic diversion: what we currently have is 
> forwarding or 3xx responses. What we might need here is what 
> eg also Diameter offers, what I would call "selective 
> temporary redirection". In Diameter, you can say "for the 
> next 10 minutes, send all traffic for {this session, this 
> domain, this user, ...} to this and that node". You could do 
> the same for SIP, the selection criteria could e.g. be 
> pre-established, standardized profiles or fully dynamic.
> A solution would probably need to support both implicit and 
> explicit alternative hosts, ie the system in overload must be 
> able to express "send your traffic to these nodes instead" 
> but also "to any node other than me"
> 
> For throttling we have 503, which only applies to a single 
> request. What we might need here is a mechanism that allows a 
> node to respond with classification criteria (for example 
> "all dialog creating requests", or something more dynamic 
> like IMS initial filter criteria) and something like shaper 
> settings, eg minimum intervals between requests, max requests 
> per time interval, etc. Again, such a filter would probably 
> have a suggested time period
> 
> My 2 cents,
> 
> Jeroen
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP