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

From: Janet P Gunn <[email-masked]>
Date: Mon, 4 Mar 2013 15:59:31 -0500

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 <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Cc:     Volker Hilt <[email-masked]>
Date:   02/11/2013 02:35 AM
Subject:        Re: [sip-overload] WG Last Call for 
draft-ietf-soc-overload-control-12
Sent by:        [email-masked]

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 (
[email-masked]), 
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
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 6 Mar 2013 21:06:54 -0500

Sec 5.10.2 Rejecting Requests at an overloaded server.

I agree with the concept
“It would be fair to devote the same amount
   of processing at the overloaded server to the combination of
   rejection and processing from a non-participating client as the
   overloaded server would devote to processing requests from a
   participating client.”

But how is the server to know how much it “would devote to processing 
requests from a  participating client.” Especially under the loss scheme.

It seems to me that it would make more sense to estimate
R = ratio of (processing required to reject a request) to (processing 
required to process a request)

Then for the loss algorithm, if the server would have set oc=x, it should 
reject (1+R)x % of the requests from the non participating client.

For the rate algorithm,   if the server would have set oc=x, it should 
reject anything over x/ (1+R) requests per second from the non 
participating client.

Sec 6.2
“some algorithm called "A".”

Is there any way to be sure that, when the client says “A” and the server 
says “A”, they mean the same thing?

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

thanks a lot
Salvatore

Thank you,

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Mar 2013 10:26:54 -0500

On 02/11/2013 02:59 AM, [email-masked] wrote:
> I just have one comment:
>
> Section 5.10.2 says that the response sent by a SIP server to
> non-participants clients in case of overload is a 503 without the
> Retry-After header. I did not find any text about the response sent by
> participating clients when they have to reject a request. I assume they
> should send a 503 without the Retry-After header as well. I would
> suggest adding the following sentence at the end of 5.10, after “it will
> need to reject these requests”: In such cases, the SIP client shall
> reply to the requests with a 503 response without the Retry-After header.

Bruno: Sorry for the delay.  Catching up with pending email on SOC.

I had a look at Section 5.10.2 and Section 5.10 where you propose to add
the above sentence.

S5.10 talks about a "SIP client" --- I am trying to figure out if we
meant a UAC or a proxy.

If this is a proxy, then the behaviour of that is already enumerated in
S5.10.2 using the same sentence you specify above.

If this is a UAC and it supports overload control, then it has already
received overload control feedback from the downstream overloaded
server.  It will act accordingly.

If this is a UAC and it does not support overload control, then it will
simply wait for a final response from the downstream server.  The UAC,
since it does not support overload control, will unfortunately keep
sending requests downstream.

As such, I am not sure if we need to add anything at all.  But I am open
to suggestions.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Mar 2013 10:30:32 -0500

Janet: Sorry for the delay, circling back to close issues on SOC.

Your suggestion below sounds reasonable.  I will modify the last
paragraph of S1 as you indicate.

On 02/21/2013 04:20 PM, Janet P Gunn wrote:
> OK, finally getting to this.
>
> In section 1, the last paragraph ("this document defines...") seems to
> miss the main point, which is a protocol for COMMUNICATING overload
> information.
>
> Therefore, I would suggest changing
>
>   "  This document defines the general behaviour of SIP servers and
>     clients involved in overload control in Section 5.  In addition,
>     Section 6 specifies a loss-based overload control scheme.  SIP
>     clients and servers conformant to this specification MUST implement
>     the loss-based overload control scheme.  They MAY implement other
>     overload control schemes as well."
>
> to
>
> "   This document defines the protocol for communicating overload
>     information between SIP servers and clients, so that clients can reduce
>     the volume of traffic sent to overloaded servers, avoiding congestion
>     collapse, and increasing usefull throughput. Section 4 describes the
>     Via header parameters used for this communication.  The general
>     behaviour of SIP servers and clients involved in overload control
>    is described in Section 5.  In addition,
>     Section 6 specifies a loss-based overload control scheme.  SIP
>     clients and servers conformant to this specification MUST implement
>     the loss-based overload control scheme.  They MAY implement other
>     overload control schemes as well."

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Mar 2013 10:56:35 -0500

On 03/04/2013 02:59 PM, Janet P Gunn wrote:
> overload algorithm selection.[...]

Janet: Changed as suggested.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Mar 2013 11:01:25 -0500

Janet: Please see inline.

There are two open questions resulting from Janet's feedback below.
Some WG input will be needed to close them.  Please see inline.

On 03/06/2013 08:06 PM, Janet P Gunn wrote:
> Then for the loss algorithm, if the server would have set oc=x, it
> should reject (1+R)x % of the requests from the non participating client.
>

My question to the WG would be whether we want to go into this level
of detail or simply leave it to the implementation to know how much
it spends in processing requests from clients?

> Is there any way to be sure that, when the client says “A” and the
> server says “A”, they mean the same thing?

We register the Via header field parameter (S11), but we do not
establish a registry for the tokens that go into the "oc-algo"
parameter.

Another question to the WG: do we need to establish a registry for
the tokens that need to go into the "oc-algo" parameter?

Thanks,

- vijay

---

From: <[email-masked]>
Date: Fri, 22 Mar 2013 16:41:48 +0000

Hi Vijay,

I realize that the relation between my question and 5.10.2 was a bit confusing. I had in mind the following scenario:

A SIP Client (Proxy or a B2BUA) receives a request from a UAC and has to forward it to an overloaded downstream server. This Proxy or B2BUA has received overloaded control feedback from the overloaded server. Because of that it has to reject some requests received from the upstream UAC (It could also send it to another destination but as mentioned in clause 5.10: "In many cases, however, it will need to reject these requests"). 

So my question is: Which SIP response to send in this case? I assume & "503 (Service Unavailable)" response without the Retry-After header would be appropriate but I did not find it explicitly stated in the document.

Regards,
Bruno

> -----Message d'origine-----
> De : Vijay K. Gurbani [mailto:[email-masked]]
> Envoyé : vendredi 22 mars 2013 16:27
> À : CHATRAS Bruno OLNC/OLN
> Cc : Salvatore Loreto; [email-masked]; Volker Hilt
> Objet : Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12
> 
> > participating clients when they have to reject a request. I assume
> > they should send a 503 without the Retry-After header as well. I would
> > suggest adding the following sentence at the end of 5.10, after "it
> > will need to reject these requests": In such cases, the SIP client
> > shall reply to the requests with a 503 response without the Retry-After
> header.
> 
> I had a look at Section 5.10.2 and Section 5.10 where you propose to add the
> above sentence.
> 
> S5.10 talks about a "SIP client" --- I am trying to figure out if we meant a
> UAC or a proxy.
> 
> received overload control feedback from the downstream overloaded server.  It
> will act accordingly.
> 
> If this is a UAC and it does not support overload control, then it will simply
> wait for a final response from the downstream server.  The UAC, since it does
> not support overload control, will unfortunately keep sending requests
> downstream.
> 
> As such, I am not sure if we need to add anything at all.  But I am open to
> suggestions.
> 
> Thanks,
> 
> - vijay
> --

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Mar 2013 11:52:43 -0500

On 03/22/2013 11:41 AM, [email-masked] wrote:
> Hi Vijay,
>
> I realize that the relation between my question and 5.10.2 was a bit
> confusing. I had in mind the following scenario:
>
> A SIP Client (Proxy or a B2BUA) receives a request from a UAC and has
> to forward it to an overloaded downstream server. This Proxy or B2BUA
> has received overloaded control feedback from the overloaded server.
> Because of that it has to reject some requests received from the
> upstream UAC (It could also send it to another destination but as
> mentioned in clause 5.10: "In many cases, however, it will need to
> reject these requests").
>
> So my question is: Which SIP response to send in this case? I assume
> & "503 (Service Unavailable)" response without the Retry-After header
> would be appropriate but I did not find it explicitly stated in the
> document.

Bruno: OK, I will update as you suggest.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 25 Mar 2013 11:01:37 -0500

On 02/17/2013 04:49 PM, NOEL, ERIC (ERIC C) wrote:
> Salvatore,
>
> I read the document and have a few comments:

Eric: Sorry for the delay; finishing up WGLC comments related to the
draft.  Please see inline.

> - Typos:
> + Section 5.4 page 12, second paragraph "... is larger than the value
>  stored value, ...." --> "... is larger than the stored value, ..."
> + Section 6.2 page 18, 7th paragraph, "20% for 1s." --> "20% for
>  0.5s" or "oc-validity=500"  --> "oc-validity=1000"

Fixed.  Thanks for a close read.

> - Questions:
> + Section 4.1 page 6, 4th paragraph, why using SHOULD and not MUST to
>  describe the client behavior upon receiving a response with the oc
>  parameters filled in. This is in contrast with section 5.5 page 12,
>  first paragraph, where a SIP client MUST honor overload control
>  values it receives from downstream neighbors.

Changed SHOULD to MUST.

> + Section 4.4 page 8, 4th paragraph, following a sequence number
>  overflow, the server must reset the oc-seq parameter. Do we incur the
>  risk of having the client ignore all server requests with the new
>  oc-seq until oc-validity expires? Or does the client need to be able
>  to identify when oc-seq was reset?

That is a good question.  I think that this an exceptional case and
probably best handled by alerting the implementer of this instead of
trying to be prescriptive using rfc-2119 language.

To that extent, I can add some explanatory text as the last paragraph
of S4.4 as follows:

    Due to an overflow, client implementations should be prepared to
    receive an "oc-seq" parameter whose value is less than the previous
    value.  Client implementations can handle this by continuing to
    perform overload control until the "oc-validity" related to the
    previous value of "oc-seq" parameter expires.

If someone has a better way to handle this case, please let me know.

> + Section 7, should there be any mention of draft-soc-overload-rate-control?

draft-soc-overload-rate-control is mentioned already as a companion
overload control scheme throughout the document.  Thus I see no specific
reason to mention it in S7.

Thanks,

- vijay