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

[Jonathan Rosenberg <jdrosen at cisco.com>]

I've submitted an update to the overload requirements document. I've 
made some changes based on list feedback since the last meeting. Until 
the document appears in the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-overload-reqs-01.txt

I didnt submit as a WG -00 since, AFAIK, we have no charter item for 
this work and there can't be a work item for it until that happens.

We also are fortunate to have had two documents produced that propose 
solutions to meet the requirements:

http://www.ietf.org/internet-drafts/draft-malas-sipping-congestion-header-01.txt
http://www.ietf.org/internet-drafts/draft-hilt-sipping-hopbyhop-overload-00.txt

I think these two drafts are a good start. However, there are many 
issues to be addressed that are not covered by the drafts. Here are some 
thoughts on some of the issues and design choices involved here:

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.

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.

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.

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.

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.

ISSUE 6: What is the temporal scope of reported congestion information?

When an upstream element receives congestion information, how long does 
it consider it valid for? What does it do when it receives no 
information from a downstream element? What does it do if it cannot 
reach a downstream element?

ISSUE 7: How does the system work for upstream elements which are not 
"servers"

I tend to think of the overload mechanism as having two modes. One mode 
is where an element knows of all of the upstream elements sending it 
traffic. It uses this knowledge to figure out what kind of rate to 
proportionally allocate to each upstream element.

In the other mode, we have somethign like an edge proxy, which has many 
many clients that connect to it. How does that edge element implement 
overload handling? Certainly it does; if the network as a whole is 
overloaded, you need to push back to the actual source so that the 
overall load being sent into the network is reduced. That source are the 
endpoints themselves. In this mode, the existing 503 mechanism works 
better. But, you want the edge proxy to push back gradually, sending 503 
(or something else) to some fraction of the clients, so that you reduce 
the input load proportionally.



I'm sure there are many more issues and many other ways to look at them. 
Hopefully this helps get discussions going on what a mechanism document 
needs to cover.

Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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