[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Overload/Congestion mechanisms - design choices andissues
Jeroen,
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.
I agree. The upstream neighbor of a proxy does not need to know which
part or resource of the proxy is overloaded. It just needs to know that
the proxy is overloaded and not able to process all messages.
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 don't understand this assumption. The upstream neighbor of a proxy
makes routing decisions in the non-overloaded case. Thus, it knows about
the next hop proxies it can route a message to (e.g. via DNS) and can
make routing decisions based on this and possibly other information or
local policy. Since the upstream neighbor of a proxy under load makes
routing decisions in the regular case, it seems natural to have this
proxy make the routing decision if the downstream proxy is overloaded.
This also has the advantage that the overloaded proxy does not have to
worry about finding a good alternative target. It can leave this
decision to the less loaded upstream neighbor (which would do the same
decision in the non-overload case). This reduces the processing required
for the overloaded proxy, which will help it to recover.
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"
I think there are a number of issues with an explicit redirection:
- the overloaded proxy would need to monitor the proxy it is redirecting
traffic to to avoid that it is redirecting traffic to a proxy that is
overloaded as well. This seems to be a lot of work for the proxy that is
already overloaded.
- even if the proxy does this monitoring, the explicit redirection can
cause oscillation (something we wanted to avoid in the first place).
Assume a proxy redirects traffic to another proxy that still has
capacities left. This would cause this proxy to go into overload state.
Meanwhile the previously overloaded proxy is freed up so that other
proxy (which is now overloaded) can redirect traffic back again. Thus
the traffic would hit the first proxy again and we would be back at
square one.
- as you mentioned, the redirection may be per-session/domain/user,
which by itself seems to be a complex task for an overloaded proxy.
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
The problems of 503 are well documented. The header field we have
proposed enables a proxy to ask the upstream neighbor to lower the
amount of traffic that is forwarded downstream.
Thanks,
Volker
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP