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

[Volker Hilt <volkerh at bell-labs.com>]

Jonathan,

thanks for the feedback on this topic. Some thoughts on the issues 1 - 5 
are inline.
> ISSUE 1: inband with SIP vs. parallel protocol
>
> One approach to solving the overload mechanism is to extend SIP with new 
> information to report overload, as both drafts have done. Another 
> approach is to design a parallel protocol that runs between elements 
> which you could apply to any other protocol, SIP or otherwise. This is 
> the approach proposed in GOCAP, which Steve posted a reference to.
>
> My personal opinion is that I prefer a SIP extension. There are several 
> reasons for this. The main one is that a parallel protocol is inherently 
> more complicated, as it requires its own syntaxes, state machines, 
> messages, and so on, and also adds complexity due to the need to define 
> interfaces into the elements whose load is being managed. As such, I 
> think it raises the bar much higher for implementation, and I think this 
> protocol should be simple as possible to drive implementation. We 
> already have some overload management in SIP; it just doesn't work well. 
> Its totally appropriate to extend SIP to improve whats there.
I fully agree (obviously).

> ISSUE 2: how to make sure that overload information passed in SIP 
> messages is only processed by the upstream server
>
> This issue is largely a SIP machinery problem, and there are several 
> solutions. A few are proposed in Volker's draft. I personally prefer the 
> approach of including congestion information in a response, and using an 
> IP address in that header field to indicate the server for which 
> overload is being reported.
I agree. Using a new header field seems preferable since it clearly 
separates overload control from other mechanisms.

> ISSUE 3: what is the nature of the overload information
>
> Volker proposes a value between 0 and 100, and Daryl proposes a 
> multidimensional value from 0 to 5. You really can't answer this design 
> issue until you answer the next, which is one of the two BIG design 
> issues I think.
I think fundamentally there are two distinct pieces of information a 
proxy can report (the draft may have been a bit overly simplistic on this):
- its current resource usage level AND / OR
- the target load the proxy wants to receive (e.g. in messages per 
second) or the fraction of traffic that should be discarded/redirected.

The first piece of information enables an upstream neighbor to make load 
balancing/overload control decisions at its discretion. The second piece 
specifically tells the upstream neighbor *when* to react and to which 
extend.

I believe that both pieces of information are useful. The draft defines 
an implicit relation between both by setting thresholds but it might 
make sense to explicitly report both. This would decouple the tasks of 
load reporting and throttling.

> ISSUE 4: how does an element respond to overload information
>
> When an upstream element has a set of load indicators from downstream 
> elements, how does it use that information to decide which server to 
> send it to, or whether it should reject the request. How does it do this 
> in a way that keeps the network throughput up? How does it make sure 
> that it still distributes load in a reasonable way across the downstream 
> elements?
>
> This is big isssue #1.
There is yet another type of information that can be reported: a proxy 
could explicitly tell the upstream neighbor *what* to do. For example, 
the proxy could tell the upstream neighbor to redirect a certain 
fraction of traffic to a specific proxy (e.g. a standby proxy that helps 
to resolve overload) or that a fraction of traffic should be rejected 
(if the proxy knows that no other paths will succeed).

This option would only make sense if the overloaded proxy has 
information about how to resolve the overload condition the upstream 
neighbor can't access. In addition it requires the already overloaded 
proxy to generate these directions to upstream proxies, which may differ 
based on the request targets.

The load status reports a proxy receives from its downstream neighbors 
should enable it to distributed load across them. This and other 
information used for routing should provide a basis for making 
reasonable decisions about which server to route to or whether to reject 
a request.

> ISSUE 5: how does a downstream element determine which incoming traffic 
> to process based on upstream server?
>
> There are many aspects to this issue. One of the harder ones is a 
> policing function. Think of a server has having input queus, one for 
> each upstream element. The server processes requests from an upstream 
> element by taking a request off that queue. What is the queuing 
> discipline implemented by this server? If you just do something basic 
> like round-robin, you end up in an interesting situation of rewarding 
> upstream elements which DONT implement the mechanism! There needs to be 
> a way of verifying that elements are sending at a reduced rate based on 
> the congestion indications, and of determining a rate to allocate to 
> upstream elements which don't support it.
>
> This is big issue #2.
Yes, this is an interesting problem. A proxy that implements overload 
control should certainly be rewarded and not punished. An obvious 
solution might be to send 503s to upstream neighbors that do not react 
to overload reports. However, this assumes that a proxy can identify 
these proxies and it will bring back the known problems of 503. On the 
other hand, since these proxies don't support overload control, this 
should not come as a total surprise.

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