Subject: [dispatch] Fwd: Re: Chartering SIP Overload

From: Volker Hilt <[email-masked]>
Date: Mon, 18 Jan 2010 16:23:56 -0500

Re-sending to DISPATCH.

Subject: Re: [dispatch] Chartering SIP Overload
From: Volker Hilt <[email-masked]>
To: Lars Eggert <[email-masked]>
Cc: Spencer Dawkins <[email-masked]>, Dean Willis <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, DISPATCH <[email-masked]>, "[email-masked]" <[email-masked]>, Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jan 2010 14:06:19 -0600

Lars,

here is a list of papers on SIP overload that are referenced in 
http://tools.ietf.org/html/draft-ietf-sipping-overload-design-02:
- Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP 
Servers", IEEE International Conference on Network Protocols (ICNP'08), 
Orlando, Florida, October 2008.
- Noel, E. and C. Johnson, "Initial Simulation Results That Analyze SIP 
Based VoIP Networks Under Overload", International Teletraffic Congress 
(ITC'07), Ottawa, Canada, June 2007.
- Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol 
(SIP) Server Overload Control: Design and Evaluation, Principles", 
Systems and Applications of IP Telecommunications (IPTComm'08), 
Heidelberg, Germany, July 2008.

More papers are referenced in these papers.

In addition, there were presentations at IETF meetings including
- IETF 74 SIPPING 
(http://www.ietf.org/proceedings/74/slides/sipping-11/sipping-11.htm),
- IETF 73 SIPPING 
(http://www.ietf.org/proceedings/73/slides/sipping-8/sipping-8.htm),
- IETF 71 TSVAREA 
(http://www.ietf.org/proceedings/71/slides/tsvarea-3/tsvarea-3.htm)

Volker

On 1/18/2010 2:17 PM, Lars Eggert wrote:
> Hi,
>
> could someone send me a pointer to the latest experimental or
> simulation results for the various proposed mechanisms? I want to
> make sure I've seen the latest data.
>
> I'm not on this list, so apologies if I have missed this.
>
> On 2010-1-18, at 20:56, Spencer Dawkins wrote:
>> - it seems appropriate to use a less restrictive strategy here -
>> we shouldn't encourage people to ignore our maturity levels
>> completely, and we shouldn't use our maturity levels to encourage
>> people to continue deploying standards-track mechanisms that have
>> already been observed to fail, and are not self-correcting when
>> they fail, on production networks.
>
> I fully agree that the proposed mechanisms (that I've seen) are
> better than what we currently have (which is almost nothing.) I'm by
> no means opposed to doing this work. It's also extremely encouraging
> that these mechanisms are actively being developed, analyzed,
> deployed and monitored.
>
> My main concern in a nutshell is: Do we have have one mechanism of
> which we are confident that it (1) operates very well in many
> deployment scenarios, (2) degrades gracefully (i.e., doesn't
> oscillate, etc.) in cases where it doesn't work very well and (3) is
> never worse than what we currently have?
>
> If we do, then PS is appropriate. If we don't, then IMO publishing PS
> sends the wrong signal to deployers.
>
> I've personally not seen enough data to convince me of (1) and (2) -
> but maybe I've missed some work, hence the request at the beginning
> of the email.
>
> Lars