Subject: [Sipping] Comments on draft-rosenberg-sipping-overload-reqs-00

From: Janet P Gunn <[email-masked]>
Date: Tue, 21 Mar 2006 19:30:12 -0500

I agree that it is important to be able to have greater resolution on the
overload controls, e.g. a percentage load shedding rather than all or
nothing.

But I think it would be useful to be qualitative as well as quantitative.

 It makes sense to block some types of messages rather than others.  If the
SIP server is having difficulty processing the workload associated with
currently registered devices, it doesn’t make sense to register new
devices.  Therefore the first level of load shedding might block SIP
REGISTER messages, while accepting other messages from devices that are
already  registered. The next level of load shedding might block SIP INVITE
messages, while accepting  messages  for sessions which are in the process
of being established, or are already established.  And so on, with the last
set of messages to be blocked probably being SIP BYEs.

In a more specific comment, for requirement
   REQ 13: The mechanism must allow a proxy to prioritize requests, so
      that certain ones, such as call for emergency services, are still
      processed.
Would it be possible to also prioritize messages based on RPH?

Thanks

Janet

_______________________________________________
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: Shida Schubert <[email-masked]>
Date: Tue, 21 Mar 2006 16:59:36 -0800

Comments inline.

> Would it be possible to also prioritize messages based on RPH?
 Isn't this implementation requirement? Sounds like you are trying to 
reserve resources for
 priority/emergency calls and does not sound like a protocol requirement..

 Thanks.
> Thanks
>
> Janet
> ------------------------------------------------------------------------
>

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 21 Mar 2006 20:23:41 -0500

I interpreted it more as that the protocol should not prevent the
implementation from prioritizing emergency requests, so they are still
processed..

             Shida Schubert                                                
             <[email-masked]                                             
             >                                                          To 
                                       Janet P Gunn/FED/CSC@CSC            
             03/21/2006 07:59                                           cc 
             PM                        [email-masked], Jonathan          
                                       Rosenberg <[email-masked]>,      
                                       Dennis Q Berg/FED/CSC@CSC           
                                                                   Subject 
                                       Re: [Sipping] Comments on           
                                       draft-rosenberg-sipping-overload-re 
                                       qs-00                               

                                                                           

Comments inline.

 Thanks.

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 21 Mar 2006 23:31:02 -0500

A fine draft.  But one nit:  Unless I'm missing something, Requirements
8 and 9 are the same.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2006 15:11:30 -0500

Exactly right. There is no expectation of new protocol mecahnisms to 
support this; just that it shouldn't break the ability of a proxy to do 
it. Thus, its worth mentioning.

> Would it be possible to also prioritize messages based on RPH?

sure. The requirement is not saying you can only prioritize emergency 
calls; it just says that emergency calls are an example. Since, per 
above, the prioritization is a local decision, anything can be used.

-Jonathan R.

Janet P Gunn wrote:

>> It makes sense to block some types of messages rather than others.  If
> 
> the
> 
>>already  registered. The next level of load shedding might block SIP
> 
> INVITE
> 
>>messages, while accepting  messages  for sessions which are in the
> 
> process
> 
>>of being established, or are already established.  And so on, with the
> 
> last
> 

-- 
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