Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm

[Adam Roach <[e-mail]>]

No, now I'm even more confused. I have a rather long list of things I 
think need to change here, but I don't want to throw them all out for 
fear of them being confused with each other.

Let's start simple, with the most fundamentally important question: 
where is "get_sip_msg()" getting a message from?

(a) Some internal queue of outgoing SIP messages to be sent to the network
(b) A network interface (or some abstraction thereof) representing 
incoming SIP messages
(c) Somewhere else

/a

On 3/8/12 12:08 PM, Vijay K. Gurbani wrote:
> Adam, Eric: Thank you for looking over the algorithm.  I was hoping
> that more eyeballs will look at it and uncover problems.  The
> baroqueness you refer to is an artefact of trying to come up with
> a cohesive algorithm based on a simple textual description [1] coupled
> with ensuing discussions on the list on how to specify local policy when
> the server is overloaded and bolstered by some underlying unstated
> assumptions.
>
> In any case, I have modified the algorithm based on your suggested
> changes with unstated assumptions filled out, for instance,
> in the algorithm below, I have included more details on message
> prioritization that occurs for category 2 messages under overload.
> In the ealier iteration, I had simply stated in text that if there
> are not enough messages in category 1, then client may use
> "local policies" to target messages in category 2.
>
> With the algorithm relatively fresh in our minds, let's see if what
> appears below addresses your comments.  Note that I have also fixed
> category 1 / category 2 messages to be a 80/20 mix instead of a
> 40/60 mix earlier.  It seems appropriate that the corpus of messages
> that are subject to reduction be more than those that are not (unless
> an emergency situation is occurring).
>
> Thank you for pointing out where the errors lie!  Please take a look
> at the updated algorithm below and lets see if we can work at making
> this any better.
>
> cat1 := 80.0         // Category 1 --- subject to reduction
> cat2 := 100.0 - cat1 // Category 2 --- Not subject to reduction
>                      // 80/20 mix.
> while (true)  {
>    sip_msg := get_sip_msg() // Next SIP message to process, could be a
>                             // request or a response
>
>    if (is_response(sip_msg)) {
>        if (sip_msg has oc parameter values)  {
>            create_or_update_oc_context()  // For the specific server
>            // that sent the response, create or update the oc context;
>            // i.e., extract the values of the oc-related parameters
>            // and store them for later use.
>        }
>        process_msg(sip_msg)  // Rest of normal processing occurs on
>        // the response, which may include consuming it if the client
>        // is a user agent or sending it upstream if a proxy
>    }
>    else if (is_request(sip_msg))  {
>       destination := get_next_hop(sip_msg)
>       oc_context := get_oc_context(destination)
>
>       if (oc_context == null)  {
>           process_msg(sip_msg) // Process it normally by sending the
>           // request downstream since this particular destination
>           // is not subject to overload
>       }
>       else  {
>          // Determine if server wants to enter in overload or is in
>          // overload
>          in_oc := extract_in_oc(oc_context)
>
>          oc_value := extract_oc(oc_context)
>          oc_validity := extract_oc_validity(oc_context)
>
>          if (in_oc == false or oc_validity is not in effect)  {
>             process_msg(sip_msg) // Process it normally by sending the
>              // request downstream since this particular destination
>              // is not subject to overload.  Optionally, clear
>              // the oc context for this server (not shown).
>          }
>          else  {
>             category := assign_msg_to_category(sip_msg)
>             drop_msg := 0
>             pct_to_reduce := min(100, oc_value / cat1 * 100)
>
>             r := random()
>             if (r <= pct_to_reduce)  {
>                drop_msg := 1
>             }
>
>             if (category == cat2 && drop_msg == 1)  {
>                if (local_policy(sip_msg, oc_value) says process 
> message) {
>                    drop_msg := 0  // See Note 1 below
>                }
>             }
>
>             if (drop_msg == 0) {
>                 process_msg(sip_msg) // Process it normally by sending
>                // the request downstream
>             }
>             else  {
>                // Do not send request downstream, handle locally by
>                // generating response.
>             }
>          }
>       }
>    } // is_request(sip_msg)
> }
>
> Note 1: local_policy() will have to decide whether to allow a category
>  2 request downstream if that request has been marked for discard.
>  Some discussion on how to make this decision is captured in Section
>  5.10.1.
>
>  There will be four cases to consider in figuring out how local_policy()
>  should behave.  These are enunciated below, and in these cases, t is
>  the inter-invocation time of local_policy() and oc is the value of
>  the "oc" parameter.
>
>  Case 1: t is small (<= 10 times/sec?) and oc is small (<20%?)
>  Case 2: t is large (>= 500 times/sec?) and oc is large (>70%?)
>  Case 3: t is small and oc is large
>  Case 4: t is large and oc is small
>
>  The decision in cases 1 and 3 seems simple.  In case 1, local_policy()
>  is not invoked as often and the oc value is small.  On the few
>  times that local_policy() is invoked, it could allow the request to
>  to be sent to the server.
>
>  In case 3, local_policy() is not invoked as often but the oc value
>  is large.  This implies that there are enough category 1 messages
>  that are being dropped.  On the few times that local_policy() is
>  invoked, it could allow the request to be sent to the server.
>
>  It is cases 2 and 4 that local_policy() should do something more
>  intelligent.
>
>  In case 2, local_policy() is getting invoked very
>  often and the oc is also large.  This implies that category 1
>  requests are being dropped as much as possible and it will help
>  to drop a good number of category 2 requests as well.  Thus,
>  it seems reasonable to drop all but the SOS URN [RFC5031]
>  requests and high priority RPH content requests.
>
>  In case 4, local_policy() is getting invoked very often, but the
>  oc value is small.  This implies that the bulk of traffic to be
>  dropped consists of category 2 requests.  So here, it seems
>  reasonable to drop all but the SOS URN [RFC5031] requests.
>
> [1] www.ietf.org/mail-archive/web/sip-overload/current/msg00318.html
>
> Thanks,
>
> - vijay