Subject: [Sipping] draft-rosenberg-sipping-overload-reqs recovery

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Nov 2006 18:23:59 -0800

A possible additional requirement....

Imagine a system (perhaps a single proxy) that could do 100cps. It is  
in steady state doing 80cps with very few retransmission. Then for 5  
minutes the incoming requests goes to 500cps then drops back to an  
incoming call rate of 80cps. The question is, how long before the  
system gets back to the state where it if is successfully processing  
all the 80cps?

I have seen systems that never recover - that is bad. I think one of  
the design goals is that it is at least possible to build to systems  
that recover back to steady state relatively quickly after an  
overload impulse.

_______________________________________________
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

---

From: "Poretsky, Scott" <[email-masked]>
Date: Sun, 5 Nov 2006 08:55:37 -0500

I think it is worth mentioning that there is work in the Benchmarking Methodology Working Group (BMWG) to perform this type of SIP device benchmarking.  This can be found at:

http://tools.ietf.org/id/draft-poretsky-sip-bench-term-02.txt

and

http://www.ietf.org/internet-drafts/draft-poretsky-bmwg-sip-bench-meth-00.txt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 14:17:23 -0500

> system gets back to the state where it if is successfully processing  

As soon as it can. Are you suggesting a requirement here? Seems like 
this is an implementation thing and wouldn't impact any protocol mechanisms.

> that recover back to steady state relatively quickly after an  overload 
> impulse.

Sure; but I'm not sure I see the protocol requirement.

-Jonathan R.

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 6 Nov 2006 14:32:55 -0800

Hi, Jonathan,

From: "Jonathan Rosenberg" <[email-masked]>
>> Imagine a system (perhaps a single proxy) that could do 100cps. It is  in 
>> steady state doing 80cps with very few retransmission. Then for 5 
>> incoming call rate of 80cps. The question is, how long before the  system 
>> gets back to the state where it if is successfully processing  all the 
>> 80cps?
>
> As soon as it can. Are you suggesting a requirement here? Seems like this 
> is an implementation thing and wouldn't impact any protocol mechanisms.
>
>>
>> I have seen systems that never recover - that is bad. I think one of  the 
>> design goals is that it is at least possible to build to systems  that 
>> recover back to steady state relatively quickly after an  overload 
>> impulse.
>

I may have read too much into Cullen's note, but what *I* thought was being 
discussed was a "net" incoming rate of 500 cps, and what I thought Cullen 
was saying was that when the "net" incoming rate drops back to 80 cps, the 
system should not continue to present a "gross" (new requests + 
retransmitted requests) incoming rate of 500 cps for a very long time.

That seemed more of a protocol requirement than just saying "please don't 
fall over and not get up".

Thanks,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Nov 2006 19:09:15 -0800

Clearly this was a long way from the text for a requirement but, yes,  
I was proposing that this be added as one of the requirements. I  
don't feel strongly about this and if we can't figure out how to  
express this as a requirement that is useful, I can certainly live  
with not adding it.

The reason I think it is a requirement is I can easily imagine that  
the mechanism for doing overload push-back causes the systems to fail  
in the way I described below (i.e. never recover back to steady state).

On Nov 6, 2006, at 11:17 AM, Jonathan Rosenberg wrote:

>> Imagine a system (perhaps a single proxy) that could do 100cps. It  
>> is  in steady state doing 80cps with very few retransmission. Then  
>> for 5  minutes the incoming requests goes to 500cps then drops  
>> back to an  incoming call rate of 80cps. The question is, how long  
>> before the  system gets back to the state where it if is  
>> successfully processing  all the 80cps?
>
> As soon as it can. Are you suggesting a requirement here? Seems  
> like this is an implementation thing and wouldn't impact any  
> protocol mechanisms.
>
>> I have seen systems that never recover - that is bad. I think one  
>> of  the design goals is that it is at least possible to build to  
>> systems  that recover back to steady state relatively quickly  
>> after an  overload impulse.
>

---

From: Volker Hilt <[email-masked]>
Date: Wed, 08 Nov 2006 08:18:21 -0800

I think that stability of overload control is an important requirement. 
We certainly want to avoid building something that starts to oscillate 
once it reaches overload state. It may be somehow implicit to REQ 1 
since an unstable system will hardly be able to maintain the overall 
useful throughput at a high level.

Volker

Cullen Jennings wrote:
> Clearly this was a long way from the text for a requirement but, yes, I 
> was proposing that this be added as one of the requirements. I don't 
> feel strongly about this and if we can't figure out how to express this 
> as a requirement that is useful, I can certainly live with not adding it.
> 
> The reason I think it is a requirement is I can easily imagine that the 
> mechanism for doing overload push-back causes the systems to fail in the 
> way I described below (i.e. never recover back to steady state).
> 
> 
>>> for 5  minutes the incoming requests goes to 500cps then drops back 
>>> to an  incoming call rate of 80cps. The question is, how long before 
>>> the  system gets back to the state where it if is successfully 
>>> processing  all the 80cps?
>>
>> --Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza

---

From: [email-masked]
Date: Tue, 14 Nov 2006 08:22:24 +0100

Stability is an implicit requirement of every load control and overload
protection mechanism (for network elements and networks targeting high
system and/or service availability).

The rational behind is the fact that any overload control may be modeled (&
realized) as open or closed control loop. Any control arround signalling
protocols is typically realized as closed loop (e.g. due to realtime
background).
A well designed closed control requires a proof of stability for the
intended range of operation; stability is an implicit requirement from
control theory, particularly for load control with stochastic components as
in our case here.

- Albrecht

                      Volker Hilt                                                                                                       
                      <volkerh@bell-la         To:      Cullen Jennings <[email-masked]>                                              
                      bs.com>                  cc:      sipping <[email-masked]>                                                      
                                               Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery                
                      08.11.2006 17:18                                                                                                  

Volker

---

From: "SUNIL J. KUMAR" <[email-masked]>
Date: Tue, 14 Nov 2006 13:56:25 +0530

Hi,
 
Can any one provide info on all possible failure scenarios when a SIP message is declared as Malformed Message at:
 
1. UAS for all received SIP Requests
2. UAC for all received SIP Responses
 
Similarily, is there anything related to SDP Malformed Body?
 
Thanks,
Sunil

---

From: "Geneiatakis Dimitris" <[email-masked]>
Date: Tue, 14 Nov 2006 10:36:19 +0200

Hi, 
You can find information about malformed messages in the following:
1) PROTOS test suite, http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html
2) www.snocer.org

Cheers 
Dimitris

--------------------------------------------------------------------------------
Dimitris Geneiatakis
Research Assistant
Laboratory of Information and Communication Systems Security (Info-Sec-Lab)
Department of Information and Communication Systems Engineering
University of the Aegean
Karlovassi, Samos, GR-83200, GREECE
Tel: +30-22730-82247
Fax: +30-22730-82009
e-mail: [email-masked]
--------------------------------------------------------------------------------

-----Original Message-----
From: SUNIL J. KUMAR [mailto:[email-masked]]
Sent: Tue 11/14/2006 10:26
To: [email-masked]
Subject: [Sipping] SIP Malformed messages
 
Hi,

 
 
Thanks,
Sunil

---

From: "Gaurav Kheterpal" <[email-masked]>
Date: Tue, 14 Nov 2006 14:30:14 +0530

For a vendor independent/ standardized approach, you may refer to the 'SIP
Torture Tests' on http://www.cs.columbia.edu/sip/sipit/torture.html

It contains an exhaustive use cast list to ensure max inter-operability with
other vendors & compliance to specifications.

You may also refer to the following draft for a protocol independent
approach:

http://tools.ietf.org/wg/speermint/draft-niccolini-speermint-voipthreats-00.
txt

Regards,
Gaurav

  _____  

From: Geneiatakis Dimitris [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 2:06 PM
To: SUNIL J. KUMAR; [email-masked]
Subject: RE: [Sipping] SIP Malformed messages

Hi,
You can find information about malformed messages in the following:
1) PROTOS test suite,
http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html
2) www.snocer.org

Cheers
Dimitris

----------------------------------------------------------------------------
----
Dimitris Geneiatakis
Research Assistant
Laboratory of Information and Communication Systems Security (Info-Sec-Lab)
Department of Information and Communication Systems Engineering
University of the Aegean
Karlovassi, Samos, GR-83200, GREECE
Tel: +30-22730-82247
Fax: +30-22730-82009
e-mail: [email-masked]
----------------------------------------------------------------------------
----

-----Original Message-----
From: SUNIL J. KUMAR [mailto:[email-masked]]
Sent: Tue 11/14/2006 10:26
To: [email-masked]
Subject: [Sipping] SIP Malformed messages

Hi,

Can any one provide info on all possible failure scenarios when a SIP
message is declared as Malformed Message at:

Thanks,
Sunil

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Nov 2006 21:32:52 -0500

I think its reasonable to make it an explicit requirement. How about:

<t hangText="REQ 21:"> The overload mechanism should ensure that the
system remains stable. When the offered load drops from above the
overall capacity of the network to below the overall capacity, the
throughput should stabilize and become equal to the offered load.
</t>

-Jonathan R.

---

From: "SUNIL J. KUMAR" <[email-masked]>
Date: Wed, 15 Nov 2006 22:20:22 +0530

Hi,

I am developing a SIP ALG as B2BUA sitting along with NAT/Firewall on the boundary of the network.

I am covering one scenario like:

1.	SIP Proxy/registrar located in the DMZ: The users UA1 and UA2 sitting on a private (trusted) network, are to be registered with the SIP Proxy/registrar in the DMZ. 

                             Private Network                      |                  Public Network

                                                                            |

UA1-----------------|--------|                   |----------------|                                                                      |----------------|

                                 | switch |-------------| ALG(B2BUA)|--------------<Internet>----------------------|proxy/Registrar |----------UA3

UA2-----------------|--------|                   | NAT/FW        |                                                                      |----------------| 

                                                                 |----------------|

                                                                            |

                                                                            | DMZ

                                                                            |

                                                                 |----------------|

                                                                 |proxy/Registrar |

                                                                 |----------------|

                                                                            |

                                                                            |

 In this case, when UA1 and UA2 send a Register request, will reach SIP ALG(B2BUA) first as if it is UA1's outbound proxy, where from it will get forwarded to the Proxy/Registrar in DMZ.

Incoming Call:

At some later point of time when UA3 in public network makes a call to  UA1, the what should be the path of INVITE from UA3 to UA1? When B2BUA makes a DNS lookup, it gets resolved as the proxy in DMZ. 

What should be the response path?

Outgoing Call:

When UA1 in private network makes a call to UA3 in public, what should be the path of INVITE in this scanrio?

What should be the response path?

Regards,

Sunil

---

From: Volker Hilt <[email-masked]>
Date: Wed, 15 Nov 2006 17:34:37 -0500

I think the requirement looks good.

Volker

Jonathan Rosenberg wrote:
>> Hilt                                                                                                       
>>                       <volkerh@bell-la         To:      Cullen 
>> Jennings 
>> <[email-masked]>                                              
>>                       bs.com>                  cc:      sipping 
>> <[email-masked]>                                                      
>>                                                Subject: Re: [Sipping] 
>> Re: draft-rosenberg-sipping-overload-reqs recovery                
>>                       08.11.2006 
>> 17:18                                                                                                  
>>                                                                                                                                         
>>
>>
>>
>>

---

From: [email-masked]
Date: Thu, 16 Nov 2006 08:49:35 +0100

Agree to make an explicit requirement, but the current proposal is now
containing two requirements in my understanding.
One related to the stability criteria, and one related to performance (->
throughput) under overload.
The 2nd one is so far only considering throughput ("maximize throughput, =
equal to offered load"), but not the requirement of bounding response times
of (SIP) messages. A successfully processed SIP message and the
correspondent response time are tightly coupled. A successfully processed
message, but with too much delay, is typically meaningless. (The maximum
response time is typically given by SIP protocol timers, or timers of the
SIP served application, or behaviour of human beings behind a UA, or ...)

Like to split them therefore into two:

<t hangText="REQ 21:"> The overload mechanism should ensure that the
system remains stable independent of the offered load (i.e., in the entire
load range).
</t>

<t hangText="REQ 22:"> When the offered load drops from above the
overall capacity of the network to below the overall capacity, the
throughput should stabilize and become equal to the offered load (under
steady-state conditions).
Response times (or system times; given by service time and all waiting
times within the SIP entity) should be below a maximum value under all load
conditions.
</t>

- Albrecht

                      Volker Hilt                                                                                                     
                      <volkerh@bell-la         To:      Jonathan Rosenberg <[email-masked]>                                        
                      bs.com>                  cc:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings <[email-masked]>,      
                                               sipping <[email-masked]>                                                             
                      15.11.2006 23:34         Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery              

Volker

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 16 Nov 2006 05:42:08 -0600

Is requirement #22 a step function, or does it support a gradual
recovery? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:50 AM
To: Volker Hilt
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
recovery

Agree to make an explicit requirement, but the current proposal is now
containing two requirements in my understanding.
One related to the stability criteria, and one related to performance
(->
throughput) under overload.
The 2nd one is so far only considering throughput ("maximize throughput,
=
equal to offered load"), but not the requirement of bounding response
times
of (SIP) messages. A successfully processed SIP message and the
correspondent response time are tightly coupled. A successfully
processed
message, but with too much delay, is typically meaningless. (The maximum
response time is typically given by SIP protocol timers, or timers of
the
SIP served application, or behaviour of human beings behind a UA, or
...)

<t hangText="REQ 21:"> The overload mechanism should ensure that the
system remains stable independent of the offered load (i.e., in the
entire
load range).
</t>

times within the SIP entity) should be below a maximum value under all
load
conditions.
</t>

- Albrecht

                      Volker Hilt

                      <volkerh@bell-la         To:      Jonathan
Rosenberg <[email-masked]>                                        
                      bs.com>                  cc:      Albrecht
SCHWARZ/DE/ALCATEL@ALCATEL, Cullen Jennings <[email-masked]>,      
                                               sipping
<[email-masked]>

                      15.11.2006 23:34         Subject: Re: [Sipping]
Re: draft-rosenberg-sipping-overload-reqs recovery              

Volker

>>> as a requirement that is useful, I can certainly live with not
adding
>>> it.
the
>>>>> for 5  minutes the incoming requests goes to 500cps then drops
back
>>>> As soon as it can. Are you suggesting a requirement here? Seems
like
>>>>> I have seen systems that never recover - that is bad. I think one
of

---

From: "Widjaja, Indra \(Indra\)" <[email-masked]>
Date: Thu, 16 Nov 2006 10:31:00 -0600

My understanding is that #22 in "drops from above the overall capacity
of the network to below the overall capacity" can take a step function.
Requirement #22 also implies that the system is asymptotically stable.
One question is whether a stronger or more specific requirement in #22
is needed such as by how much oscillation (if it occurs) should decay
after a certain period, or what is the speed of convergence. Maybe, this
is too much?

Indra

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 6:42 AM
To: [email-masked]; Volker Hilt
Cc: Cullen Jennings; sipping
Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
recovery

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 2:50 AM
To: Volker Hilt
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
recovery

- Albrecht

                      Volker Hilt

Volker

adding
the
back
like
of

---

From: [email-masked]
Date: Fri, 17 Nov 2006 08:50:47 +0100

I could be such a function, but it must not be IMHO.
I'm not sure whether you can pose a requirement itself on specific
functions or algorithms.

[The network model in clause 6.1 reminds me a little bit to overload
control mechanisms designed for intelligent networks. The "home proxy"
relates to the IN SCP, the "edge proxy" to the SSPs, etc. The problem is
very similar in many aspects. But I can't remember a requirement itself for
the convergence/adapation/stability/... functional behaviour (arround TCAP,
INAP, served user instances of INAP; or SSP/SCP internal behaviour).]

- Albrecht

                      "Widjaja, Indra                                                                                                         
                      \(Indra\)"                     To:      "Dolly, Martin C, ALABS" <[email-masked]>, Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, 
                      <[email-masked]         "Volker Hilt" <[email-masked]>                                                    
                      l-labs.com>                    cc:      Cullen Jennings <[email-masked]>, sipping <[email-masked]>                  
                                                     Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs recovery                
                      16.11.2006 17:31                                                                                                        

Indra

-----Original Message-----
From: Dolly, Martin C, ALABS [mailto:[email-masked]]
Sent: Thursday, November 16, 2006 6:42 AM
To: [email-masked]; Volker Hilt
Cc: Cullen Jennings; sipping
Subject: RE: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
recovery

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 16, 2006 2:50 AM
To: Volker Hilt
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] Re: draft-rosenberg-sipping-overload-reqs
recovery

- Albrecht

                      Volker Hilt

Volker

adding
the
back
like
of

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Nov 2006 12:55:07 -0500

That captures what I was trying to say - thanks. I can see how people  
would say this is an obvious implicit requirement and does not need  
mentioning but I have been involved with some, uh, systems that  
failed this requirement.

On Nov 14, 2006, at 9:32 PM, Jonathan Rosenberg wrote:

>>                                                   Subject: Re:  
>> [Sipping] Re: draft-rosenberg-sipping-overload-reqs  
>> recovery                                      08.11.2006  
>> 17:18                                                                 
>>                                                                       
>>                                                                       
>>> adding it.