[sip-overload] Sec 5.8 Re: WG Last Call for draft-ietf-soc-overload-control-12

[Janet P Gunn <[e-mail]>]

I am having some problems with the basic premise of sec 5.8, Stabilizing 
overload algorithm selection.

I completely agree with the intent:
 "  Once the client and server agree on an overload control algorithm, it  
 MUST remain in effect for at least 3600 seconds (1 hour) before  another 
change occurs."
but I am having some problems with the mechanism.

The basic mechanism for selecting the algorithm is that the client 
includes a list of "algorithms supported" in the request sent to the 
server.
In return, the server includes the single algorithm that the server has 
selected from the list.

There is no opportunity for the client to either "agree" or "disagree" 
with the server.

Therefore, the onus of  "  MUST remain in effect for at least 3600 seconds 
(1 hour) before another change occurs." lies entirely with the server, not 
the client.

The existing text "the client should save the time of the last algorithm 
change with a server and only agree to change it again after a time period 
of at least 3600 seconds." is not possible to implement as the client has 
no way to tell the server "no, I am not changing algorithms yet". 

As far as I can see, if the server misbehaves by sending a new algorithm 
too soon, the client only has two options
A - Go along with the new algorithm identified by the server , even if it 
has been less than 3600 seconds
B- Drop out of the overload control process all together- stop sending ANY 
oc parameters.

I think that, in most cases, A is preferable to B.

I suggest the following rewording.

"   Realities of deployments of SIP necessitate that the overload control
   algorithm may be changed upon a system reboot or a software upgrade.
   However, frequent changes of the overload control algorithm MUST be
   avoided.  Frequent changes of the overload control algorithm will not
   benefit the client or the server as such flapping does not allow the
   chosen algorithm to stabilize.  An algorithm change, when desired, is
   simply accomplished by the SIP server choosing a new algorithm from
   the list in the client's "oc-algo" parameter and sending it back to
   the client in a response.

   The client associates a specific algorithm with each server it sends
   traffic to and when the server changes the algorithm, the client must
   change its behaviour accordingly.

   Once the server selects a specific overload control algorithm for a 
given client, it
   MUST remain in effect for at least 3600 seconds (1 hour) before
   another change occurs.  This period may involve one or more cycles of
   overload control being in effect and then being stopped depending on
   the traffic and resources at the server.

      One way to accomplish this involves the server saving the time of
      the last algorithm change in a lookup table, indexed by the
      client's network identifiers.  The server only changes oc-algo
      when the time since the last change has surpassed 3600 seconds."


Janet


From:   Salvatore Loreto <[e-mail]>
To:     "[e-mail]" <[e-mail]>
Cc:     Volker Hilt <[e-mail]>
Date:   02/11/2013 02:35 AM
Subject:        Re: [sip-overload] WG Last Call for 
draft-ietf-soc-overload-control-12
Sent by:        [e-mail]



this is just a reminder for this WG Last Call

I haven't seen yet any comment or feedback 
please we really need you spend some time to reading and reviewing the 
draft

thanks a lot
Salvatore

On 2/5/13 3:34 PM, Salvatore Loreto wrote:
Dear WG partecipants, 


Volker and I would like to initiate a second 2 weeks WG Last Call on 
draft-ietf-soc-overload-control-12 (" Session Initiation Protocol (SIP) 
Overload Control") 
http://tools.ietf.org/id/draft-ietf-soc-overload-control-12.txt

The first WGLC that we run ( 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html )
has produced a significant amount of feedback and comments that have been 
discussed and addressed in subsequent versions

Please send your reviews, as well as expression of support regarding 
document readiness for IESG (or not) either to the *soc* mailing list (
[e-mail]), 
or directly to the WG chairs (Murray Kucherawy and myself). 

Comments like "I've read the document and it is Ok to publish" or 
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs. 


The WG LC will end on Friday, February 19th. 


Thank you, 
Salvatore as an SoC co-chair. 


_______________________________________________
sip-overload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sip-overload