Subject: RE: [Sipping] Overload/Congestion mechanisms - design choices and issues

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 28 Jun 2006 08:48:18 -0400

Jeroen:

In general, I agree with you.

To do "load balancing" using SIP, it may be a stretch in SIP (but I
would go with the folks if they could solve this).

With respect "overload control," I would prefer whether we can
successfully communicate "overload [indication]" using SIP first. Once
we do this, we can then examine whether "over control" mechanisms can be
implemented using SIP.

Hope this helps.

Best regards,
Radhika R. Roy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jeroen van Bemmel
Sent: Wednesday, June 28, 2006 3:11 AM
To: Volker Hilt; Jonathan Rosenberg
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