Subject: [sip-overload] The frequency of re-negotiating overload control schemes

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 02 Sep 2011 14:41:20 -0500

Folks: One of the issues that was left rather underspecified
in draft-ietf-soc-overload-control-02 was how often should
the overload algorithms be re-negotiated.

The -02 version took a rather liberal view and simply said that
implementations must not do it too often, i.e., "... the adjacent
peers MUST NOT renegotiate the overload control algorithm class
per transaction, or per request-response message exchange."

In -03, the text around this is far more conservative and
disallows renegotiations until at least 3600s have elapsed since
the last agreement.  See the newly added Section 5.7 in -03 [1].

Please do read Section 5.7, and if there is a better way to
accomplish renegotiation, please let me know.

[1] 
http://tools.ietf.org/html/draft-ietf-soc-overload-control-03#section-5.7

Thanks,

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

---

From: Shida Schubert <[email-masked]>
Date: Tue, 6 Sep 2011 20:32:10 +0900

I think the general approach is fine.

 Client sends the list and server picks one is the current 
approach, so client has no way to present preference, 
and as far as I can tell the server has no way to change 
the algorithm unless client initiates the re-negotiation. I 
don't have any problem with that as we want to keep it 
as simple as possible but I thought I would share my 
observation.
*As far as I can read from the text, there was no text 
 saying that server can include "oc-algo" with list of 
 algorithm it supports in a response to negotiate the 
 algorithm with the client. 

 - If we want to allow client to show preference, we can 
   say that the list is composed in a order that it prefers.
   Whether server honor that or not is a different story. 

 It's also not clear to me the expected normative behavior
surrounding "oc-algo", I am assuming that  "oc-algo" only 
shows up when negotiating but it is currently not clear. So 
we should probably be clear with when "oc-algo" shows 
up so client/server both know when to set it and what it means.  

 Below are my interpretation. 

    Client sets "oc-algo" in request only when it wants to 
    negotiate the algorithm to be used. 
    
    Server knows that the negotiation is requested 
    due to the fact that "oc-algo" is present in the via. 
    It selects the algorithm and sends that in the response.

    No "oc-algo" shows up until the next negotiation phase.  

 Should we say anything about when timer runs out?

 Should we have a text mandating that if the timer runs out, 
client negotiates the algorithm on the next request it sends 
to the server??

 Regards
  Shida

On Sep 3, 2011, at 4:41 AM, Vijay K. Gurbani wrote:

> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-03#section-5.7
> 
> Thanks,
> 
> - vijay
> -- 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Sep 2011 08:11:29 -0500

>   I think the general approach is fine.

Shida: Thank you for your comments.  More inline.

>   algorithm with the client.

Right; the server simply gets to choose one from the list
provided by the client.

>     Whether server honor that or not is a different story.

That is fine with me, and more preferable than adding additional
parameters showing preference (a q-value).

>      negotiate the algorithm to be used.

I agree this part is unclear.  Here is my view, and if you
and the list agrees, I can update the draft.

For the normal sake of fault-tolerance, robustness, and
carrying as much state in the message itself, the
oc-algo appears in every request, with one important difference.
When the client first contacts the server, and thereupon every
time the timer fires, the oc-algo list will contain all
schemes supported by the client.  Once an algorithm has been agreed
to, it becomes the sole value that goes into the oc-algo parameter
until re-negotiation.  Sending it as the sole value allows for
an backup server to continue using the same algorithm agreed
to by its predecessor.

>      It selects the algorithm and sends that in the response.

Yes, the above works in both cases.  That is, when there is a list
of algorithms and when one has been chosen and the client/server
pair is in between the timer for the next negotiation going off.
In the latter case, the server does not have too much latitude at
choosing, but the former case (list of algorithms), the server
can choose afresh.

>   Should we say anything about when timer runs out?

I believe this is present in Section 5.7:

    Once the client and server agree on an overload control
    algorithm, it MUST remain in effect for at least 3600 seconds
    (1 hour) before renegotiation occurs.

> client negotiates the algorithm on the next request it sends

I believe it is already there in Section 5.7:

    Renegotiation, when desired, is simply accomplished by the
    SIP client sending a complete list of overload control
    algorithms it supports in a "oc-algo" parameter in a
    request going downstream.  The downstream server, as before, MUST
    choose one algorithm from the list and MUST pare the list down to
    include the one chosen algorithm.  The pared down list consisting of
    the chosen algorithm MUST be returned to the upstream SIP client in
    the response and stays in effect until the next renegotiation.

If the last two points you make are not clear in Section 5.7, please
let me know and I can see if I can highlight these in some fashion.

Thanks,

- vijay

---

From: Shida Schubert <[email-masked]>
Date: Wed, 7 Sep 2011 09:23:40 +0900

Hi Vijay;

 My comments inline..

> an backup server to continue using the same algorithm agreed

 Okay, fair enough. 

 I guess we should probably mandate the inclusion of "oc-algo" 
in that case. It is currently stated on 4.1 as "MAY" add an "oc-algo"..

 One can assume that not having "oc-algo" indicates that the client 
only supports or wants to use the default "loss" based algorithm but 
if that is the case we should probably have a statement saying that 
too. 

 I prefer mandating the inclusion of "oc-algo" so it is always clear 
what the client/server means/wants. 

>   the response and stays in effect until the next renegotiation.

 I must have misread it, it looks good. 

 Regards
  Shida

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Sep 2011 21:47:59 -0500

On 09/06/2011 07:23 PM, Shida Schubert wrote:
> Okay, fair enough.
>
> I guess we should probably mandate the inclusion of "oc-algo" in that
> case. It is currently stated on 4.1 as "MAY" add an "oc-algo"..
>

Shida: Great, thanks.  I will wait to see if anyone else has any
other views on this, and if not, I will go ahead and update
as agreed upon.

> I must have misread it, it looks good.

Great; thanks for giving it a good read.

Ciao,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Wed, 7 Sep 2011 08:36:02 -0400

>> what the client/server means/wants.
I agree.

Following up on the previous discussion of having the client include 
only the current algorithm. I think the selection of the algorithm is 
essentially a server issue. Once the server knows which algorithms the 
client supports it can pick one. I'm not sure what the value is of 
having the client include only the currently selected algorithm and 
trigger a renegotiation once in a while.

I think the client should always include all supported algorithms. The 
server gets to choose since it needs to shoulder the burden of 
generating the feedback for each client.

In the spirit of keeping things simple, I don't think expressing 
preferences adds much value. The client should send a flat list the 
sever can choose from.

The draft should, of course, have a discussion about chosing the 
algorithm in the server (i.e., not changing it often, etc)

Thanks,

Volker [as individual]

---

From: Shida Schubert <[email-masked]>
Date: Wed, 7 Sep 2011 22:51:03 +0900

My comments inline..

On Sep 7, 2011, at 9:36 PM, Volker Hilt wrote:

> Following up on the previous discussion of having the client include only the current algorithm. I think the selection of the algorithm is essentially a server issue. Once the server knows which algorithms the client supports it can pick one. I'm not sure what the value is of having the client include only the currently selected algorithm and trigger a renegotiation once in a while.
> 
> I think the client should always include all supported algorithms. The server gets to choose since it needs to shoulder the burden of generating the feedback for each client.

 I agre with your opinion that it is really the server side that really 
cares what algorithm it uses, so I think this is better. 

> 
> In the spirit of keeping things simple, I don't think expressing preferences adds much value. The client should send a flat list the sever can choose from.

 If client doesn't benefit from certain algorithm being selected, I agree. 

 Regards
  Shida

> 
> The draft should, of course, have a discussion about chosing the algorithm in the server (i.e., not changing it often, etc)
> 
> Thanks,
> 
> Volker [as individual]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 Sep 2011 09:27:23 -0500

On 09/07/2011 07:36 AM, Volker Hilt wrote:
> essentially a server issue. Once the server knows which algorithms
> the client supports it can pick one. I'm not sure what the value is
> of having the client include only the currently selected algorithm
> and trigger a renegotiation once in a while.

Volker: Three reasons.

Consider a case where a client/server pair has agreed on an
algorithm.  Shortly after agreement, and before the re-negotiation
timer expires, the server crashes.  A backup server takes its
place.  The client continues to operate on the previously chosen
algorithm, even if the new server supports schemes that the old
server did not.  The alternative is that if we send the complete
algorithm list, the new server may choose a different scheme
than its predecessor did, causing the client some mild discomfort.

Second, it seems more explicit for the client to send only the
algorithm agreed upon.  Sending the entire list every time forces the
server to always parse the list.

Finally, given that the Via header line length is constantly increasing,
it is advantageous not to  insert an entire list, however small it may
be.

> I think the client should always include all supported algorithms.
> The server gets to choose since it needs to shoulder the burden of

If the working group wants to go with the alternative of sending
an entire list on each request, I am perfectly happy to do so; but I did
want to at least provide a justification for not doing so.

> algorithm in the server (i.e., not changing it often, etc)

The feedback we got the previous time is that we have to do a better
job of simply saying that the algorithm should not change too often
("how long is too often?  Once a transaction?  Once a dialogue?
Once every 5 minutes?  Once every 10 requests?").  Hence the addition
of the timer with a default value of 3600s to handle the renegotiation.
If you have any alternative means to affect the same outcome
deterministically, please do let me know.

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Wed, 7 Sep 2011 10:28:25 -0400

> than its predecessor did, causing the client some mild discomfort.
I think this is a good case in which the server can switch. Otherwise 
the client forces the server into using a specific algorithm, which it 
may not even support.

> server to always parse the list.
Once everything is up and running all the server needs to do is look for 
the algorithm it is currently using. But I agree that may be slightly 
more work.

> it is advantageous not to  insert an entire list, however small it may
I think we are talking about a very small list. If you are concerned 
about the Via header length, we can make the identifiers very small.

> want to at least provide a justification for not doing so.
Fully understood!

> deterministically, please do let me know.
I think it makes sense to specify this for the server side. I.e., give 
recommendations of when the server may consider to change an algorithm.

Thanks,

Volker

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 Sep 2011 14:41:58 -0500

> the client forces the server into using a specific algorithm, which it

True; this is the flip side that I did not consider.  I simply
assumed that the server supported all schemes offered by the client,
and would therefore zero in on the singleton algorithm in the
client's list.

> about the Via header length, we can make the identifiers very small.

That is okay.  I do not forsee having too many algorithms here.

> recommendations of when the server may consider to change an algorithm.

Hmmm ... I had always assumed that this will be done on the client side.
However, if the client is sending the complete algorithm list in
every request, then it does not make sense to do it there for obvious
reasons.

So it looks like we will have to do it on the server side.  I will
update the draft as such.

Thanks,

- vijay