Subject: Re: [sip-overload] Open issue #1: algorithm agility

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 1 Dec 2010 14:54:50 +0530

Janet, 
 
Now, I got your point and it seems to be good idea. In case system is
able to negotiate the overload algorithm with its peer using
out-of-dialog mechanism, it is possible for system to indicate or infer
whether the system support overload or not using out-of-dialog.
 
Thanks
Partha

________________________________

From: Janet P Gunn [mailto:[email-masked]] 
Sent: Tuesday, November 30, 2010 8:09 PM
To: Parthasarathi R (partr)
Cc: [email-masked]; [email-masked]; Vijay K.
Gurbani
Subject: RE: [sip-overload] Open issue #1: algorithm agility

Sorry for not being clearer. 

I was referring to this purpose, which is, at least to me, analogous to
identifying the overload algorithms supported. 
" 1.  oc: This parameter serves a dual purpose; when inserted by a SIP 
       entity in a request going downstream, the parameter indicates 
       that the SIP entity supports overload control." 

I wasn't referring to this purpose, which, I agree, is dynamic and
rapidly changing- and thus fundamentally different from "I support X" 
"      When the 
       downstream SIP server sends a response, the downstream SIP server

       will add a value to the parameter that indicates a loss rate (in 
       percentage) by which the requests arriving at the downstream SIP 
       server should be reduced. (c.f.  Section 4.2, Section 4.3, 
       Section 4.4 and Section 4.5.)" 

Janet 

From: 	"Parthasarathi R (partr)" <[email-masked]> 
To: 	Janet P Gunn/USA/CSC@CSC 
Cc: 	<[email-masked]>, <[email-masked]>, "Vijay
K. Gurbani" <[email-masked]> 
Date: 	11/30/2010 09:26 AM 
Subject: 	RE: [sip-overload] Open issue #1: algorithm agility

________________________________

IMO, Inband "overload control" is used as the overload feedback
(control) information changes every moment dynamically whereas  out of
band "overload algorithm" negotiation mechanism is preferred as the
frequency at which overload algorithm change is low. 
  
Thanks 
Partha 

________________________________

From: Janet P Gunn [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, November 30, 2010 6:27 PM
To: Parthasarathi R (partr)
Cc: [email-masked]; [email-masked]; Vijay K.
Gurbani
Subject: RE: [sip-overload] Open issue #1: algorithm agility

It just seems odd to me to use an IN BAND mechanism to say "I support
Overload Control" while using an OUT OF BAND mechanism to say "I support
these algorithms for Overload Control". 

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. 

From: 	"Parthasarathi R (partr)" <[email-masked]> 
To: 	Janet P Gunn/USA/CSC@CSC 
Cc: 	<[email-masked]>, <[email-masked]>, "Vijay
K. Gurbani" <[email-masked]> 
Date: 	11/30/2010 01:08 AM 
Subject: 	RE: [sip-overload] Open issue #1: algorithm agility

________________________________

Janet, 
 
As your example indicates, the algorithm changes may happen once in a
while and the protocol has to indicate in that fashion rather than per
dialog or per transaction. 
 
Some of the out-of-dialog mechanism shall be explored to find the best
solution. 
 
Thanks 
Partha 

________________________________

From: Janet P Gunn [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, November 30, 2010 9:25 AM
To: Parthasarathi R (partr)
Cc: [email-masked]; [email-masked]; Vijay K.
Gurbani
Subject: RE: [sip-overload] Open issue #1: algorithm agility

Installation of a new software release.

From: 	"Parthasarathi R (partr)" <[email-masked]> 
To: 	Janet P Gunn/USA/CSC@CSC 
Cc: 	<[email-masked]>, <[email-masked]>, "Vijay
K. Gurbani" <[email-masked]> 
Date: 	11/29/2010 09:22 PM 
Subject: 	RE: [sip-overload] Open issue #1: algorithm agility

________________________________

Janet, 

Hope you agree that the overload algorithm does not changes per
transaction. The current solution is to pass the overload algorithm per
transaction in "oc". IMO, the current proposal is less efficient
mechanism and there are better ways to solve the same issue. 

Let me clarify that I'm not talking about pre-configured SIP server
network wherein each server aware of peers overload algorithm. From the
overload design perspective, multiple source device has to keep track of
the list of server to which they are communicating. SIP server has to
negotiate and keep track of the overload algorithm with each of its
peers. Your concern of upstream server changing frequently will be
addressed in case the overload algorithm negotiation happens whenever
the traffic is started between peers. 

But I'm not getting your point of overload algorithm changing between
two servers. The overload algorithm between two servers has to executed
in the system level of both servers. Could you please explain the
scenario wherein the overload algorithm is changed in the middle between
the given two servers. This scenario is not explained in any of SoC
document (design or requirement) till now. 

Thanks 
Partha 

________________________________

From: Janet P Gunn [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Tue 11/30/2010 3:50 AM
To: Parthasarathi R (partr)
Cc: [email-masked]; [email-masked]; Vijay K.
Gurbani
Subject: Re: [sip-overload] Open issue #1: algorithm agility

I guess it depends on how stable the environment is. 

If the set of "upstream" SIP servers rarely changes (and which
algorithms they support also rarely changes), then it may make sense to
negotiate ahead of time, and have each SIP server keep track of which
algorithm to use with each partner. 

But if the set of "upstream" SIP servers is frequently changing, and/or
the set of algorithms supported by each server is also frequently
changing, then it may make more sense to include an indication of the
algorithm, along with the "oc", parameter. 

In your scenario- the downstream SIP server already knows what the
upstream SIP servers support- there would also  be no need for the "oc"
parameter in the message generated by the upstream SIP server. But that
is not the premise of this overall approach. 

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. 
From: 	"Parthasarathi R (partr)" <[email-masked]> 
To: 	"Vijay K. Gurbani" <[email-masked]>, <[email-masked]> 
Date: 	11/24/2010 07:49 PM 
Subject: 	Re: [sip-overload] Open issue #1: algorithm agility

________________________________

Vijay, 

I like the item of negotiating overload algorithm between SIP devices
which provides extensibility to overload mechanism. IMO, the selection
of overload algorithm between two SIP devices is one time and it is less
efficient  to pass the algorithm names in each request and negotiating
in the response. In case you see the usecase where the algorithm changes
per transaction, Please explain it in more detail. As the solution aims
mainly between SIP servers with huge SIP transaction, it may be
preferred to use REGISTER or SUB/NOT mechanism for negotiating the
overload algorithm between the devices. 

Thanks 
Partha 

________________________________

From: [email-masked] on behalf of Vijay K. Gurbani
Sent: Tue 11/23/2010 5:07 AM
To: [email-masked]
Subject: [sip-overload] Open issue #1: algorithm agility 

Folks:

In [1] Janet Gunn makes a case for allowing multiple different
overload algorithms while keeping the protocol semantics the
same (i.e., we should not introduce additional parameters for newly
introduced overload control algorithms.)

The overload design team studied three distinct overload control
algorithms: loss based, rate based and windows based.  The
relative results from using any of the three is about the same,
although complexity wise, loss based is the simplest and windows-
based the more complex of the three.

draft-ietf-soc-overload-control-00 uses a loss based mechanism.

There is a need to allow for other mechanisms that may become
available later.  So how do we do this while keeping the overload
control-related parameters the same?

Starting from what Janet suggests, here is a particular proposal
to allow for future algorithm agility.

Currently, overload control is indicated by three parameters:
"oc", "oc-validity" and "oc-seq".  I propose we add a fourth,
optional, parameter "oc-algo" to the mix.  The default and
mandatory-to-implement algorithm will be loss-based, other
algorithms may be supported.  The way algorithm selection will
work is as follows:

The upstream entity inserts the "oc" parameter as usual.  If it
supports additional algorithms beyond loss-based, it will include these
in a comma-separated list in the "oc-algo" parameter, example:

INVITE sips:[email-masked] SIP/2.0
Via: SIP/2.0/TLS p1.example.net;branch=z9hG4bK2d4790.1;
received=192.0.2.111;oc;oc-algo="loss,rate,window"

...

SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;branch=z9hG4bK2d4790.1;
received=192.0.2.111;oc=20;oc-validity=500;
oc-seq=1282321615.781;oc-algo="loss"

The default value of "oc-algo" is "loss" and if an implementation
only supports loss-based, the "oc-algo" parameter can be
omitted entirely.

draft-ietf-soc-overload-control only considers the default
and mandatory-to-implement algorithm --- loss.  SIP assets that
support draft-ietf-soc-overload-control must implement loss based
algorithm and may implement others.  What those other algorithms are,
draft-ietf-soc-overload-control is not the right place to specify
these; interested authors can submit other drafts fleshing out the
details in appropriate drafts.  For instance, if an implementation
supports rate-based control, the entity will send at most X
requests per second, and if an implementation supports windows
based control, the entity will send no more than X messages
before waiting for a confirmation (the value of X is taken
from the "oc" parameter.)

The algorithm chosen between the upstream SIP entity and the
downstream server is the intersection of the algorithms supported
by both upstream entity and the downstream server.  If a multiplicity
of algorithms are supported, the downstream server decides which
exact one is picked.  The downstream server cannot pick more than
one algorithm and it cannot pick an algorithm not supported by the
upstream SIP entity.  If the downstream server chooses more than one
algorithm or if the downstream server picks an algorithm not
supported by the upstream SIP entity, overload control is not
triggered between the neighbours.

This allows folks to come up with new overload control algorithms,
but every implementation will need to at least implement the loss-
based mechanism as a common denominator.

Any discussion around this will be good to have before we get
into the interim meeting next week.

[1]
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00403.html
<http://www.ietf.org/mail-archive/web/sip-overload/current/msg00403.html

Thoughts?

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/
<http://ect.bell-labs.com/who/vkg/> 
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload
<https://www.ietf.org/mailman/listinfo/sip-overload>
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload
<https://www.ietf.org/mailman/listinfo/sip-overload>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 01 Dec 2010 09:13:13 -0600

On 11/30/2010 10:58 PM, Parthasarathi R (partr) wrote:
> It is good that we agree upon the overload algorithm negotiation for
> the first time when the traffic starts.

Partha: Thank you for your comments.  Please see inline.

> The question is whether the traffic starts has to keep track of when
> traffic stops in the implementation and has to kick start
> re-negotiation when the traffic starts again. The traffic may stop
> when the system reload (maintenance window) or software upgrade or
> late night. At least, the proposal looks vague for me. The different
> interpretation of this proposal may to lead to interop. To make it
> clear, I'm talking about when to negotiate the algorithm through SIP
> signaling and not about how system internal state is maintained.
>
> I proposed out-of-dialog mechanism as it will be clear from the
> implementation perspective between two entities.  It will ensure when
> to re-negotiate and when not.

I don't think we need an out-of-band mechanism to do algorithm
negotiation, and here are my reasons why.

First, negotiation overload control algorithms is not akin
to negotiating codecs or crypto-suites where you want to start
out with the lowest common denominator and subsequently
upgrade to better ones as the need arises.

In overload control, an algorithm will either perform or it will
not, there is no middle ground.  All the three algorithms studied
in current literature --- loss-, rate-, and windows-based ---
exhibit similar performance, and the choice on using one comes
down to minimizing implementation complexity.

Second, let's suppose that someone devises a whiz-bang algorithm
in the future that performs orders of magnitude better than the
three we currently know of.  Then implementations will, over time,
gravitate towards it.  Negotiating the whiz-bang algorithm on first
contact with the downstream server and keeping it constant if the
downstream server supports it will still be the right thing to do.
I see no reason why a pair of neighbours will want to start with
a less optimal algorithm if both of them support the whiz-bang
algorithm.  Similarly, I see no reason why a pair of neighbours
will first start with the whiz-bang algorithm and then downgrade
to a less optimal one.

Third, designing an out-of-band mechanism to do periodic
renegotiation is adding more complexity to the mix where this
complexity does not seem to be justified when the returns it
provides are questionable.

It is simple to have the upstream client keep state associated
with the downstream server, and this state is reset every
time the upstream client is restarted.  However, once the state
has been established, then it does not change.

I agree with you that the proposal I outlined in [1] is vague,
but that is because we are in the process of hashing out the
details at the present time --- and this has been good.  Notice
the discussion around 100 Trying, etc.  Once we iron out the
crude details around the proposal in [1], it will appear as a
better fleshed out proposal in a new version of the draft.  At
that point, I believe that the intent and the underlying
reasons will be much clearer.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 1 Dec 2010 10:19:24 -0500

Furthermore, relying on an advance, out-of-band, negotiation/notification 
of either "I support Overload Control" or "I support rate based overload 
control" might conflict with Req 10 of 5390:
"REQ 10:  The mechanism should support servers that receive requests
      from a large number of different upstream elements, where the set
      of upstream elements is not enumerable."

Janet

From:
"Vijay K. Gurbani" <[email-masked]>
To:
"Parthasarathi R (partr)" <[email-masked]>
Cc:
[email-masked]
Date:
12/01/2010 10:11 AM
Subject:
Re: [sip-overload] Open issue #1: algorithm agility

[1] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html

Thanks,

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 01 Dec 2010 16:40:28 +0100

I have one question. I have asked separately. But given the discussion here I wanted to understand this:

If A has to send INVITE to B and say B is already overloaded.
How does B informs A beforehand?
 
Assuming event to send first INVITE to A by B happens quite late? 
 
If we add information in INVITE response only, then first X INVITES to B will fail since B was already overloaded? 
It looks like even if sufficient window was avaialble to B it can't inform A since there was no INVITE from A?

If above conclusion is correct then sending overload information "in-band" is the right approach?

I didn't get much info from draft. Hence I ask this question.

Regards,
Rahul

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Janet P Gunn <[email-masked]>
Date: Wednesday, December 1, 2010 4:19 pm
Subject: Re: [sip-overload] Open issue #1: algorithm agility
To: "Vijay K. Gurbani" <[email-masked]>
Cc: [email-masked], [email-masked]

> > implementation perspective between two entities.  It will ensure 
> when> to re-negotiate and when not.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 01 Dec 2010 09:48:30 -0600

On 12/01/2010 09:40 AM, RahulSrivastava 71616 wrote:
> I have one question. I have asked separately. But given the
> discussion here I wanted to understand this:
>
> If A has to send INVITE to B and say B is already overloaded. How
> does B informs A beforehand?

Rahul: We can discuss the nuances of this after the virtual
interm (to begin in a few minutes.)

Until then, the short answer is that the draft [1] discusses
this condition in Section 4.7.

Thanks,

[1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-00

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 01 Dec 2010 16:59:51 +0100

No problem. Take your time.

But my question is not related to 4.7. 
4.7 talks about only requests that are transmitted and will be failed.

My question is a bit different:

A has not yet send B request. (This is the crucial point. You can assume a DNS reply has not given B's address yet).
But B knows at some point A might try to send the request. 

But B is overloaded. How does B informs about its own status to A?

I hope I made question clear.

Regards,
Rahul

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 1 Dec 2010 11:04:49 -0500

Try sec 7.1.2, the event package., for that case.
Janet

From:
RahulSrivastava 71616 <[email-masked]>
To:
"Vijay K. Gurbani" <[email-masked]>
Cc:
[email-masked]
Date:
12/01/2010 11:00 AM
Subject:
Re: [sip-overload] Open issue #1: algorithm agility

A has not yet send B request. (This is the crucial point. You can assume a 
DNS reply has not given B's address yet).
But B knows at some point A might try to send the request. 

Regards,
Rahul

******************************************************************************************
 This email and its attachments contain confidential information from 
HUAWEI, which is intended only for the person or entity whose address is 
listed above. Any use of the information contained here in any way 
(including, but not limited to, total or partial disclosure, reproduction, 
or dissemination) by persons other than the intended recipient(s) is 
prohibited. If you receive this email in error, please notify the sender 
by phone or email immediately and delete it!

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Dec 2010 17:12:36 +0100

I'm not sure how such would be useful.

How does B know it is likely to receive calls from A? Presumably because A has used B before. 

It would seem to be useful only to tell SIP entities about overload situations if you reasonably expect them to deliver SIP requests to you in the timeframe that you are overloaded. That equates very roughly to those SIP entities who are already progressing SIP requests through you.

Telling more entities only increases the load on the overloaded server.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> RahulSrivastava 71616
> Sent: Wednesday, December 01, 2010 4:00 PM
> To: Gurbani, Vijay K (Vijay)
> A has not yet send B request. (This is the crucial point. You 
> can assume a DNS reply has not given B's address yet).
>  This email and its attachments contain confidential 
> information from HUAWEI, which is intended only for the 
> person or entity whose address is listed above. Any use of 
> the information contained here in any way (including, but not 
> limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this email in 
> error, please notify the sender by phone or email immediately 
> and delete it!
>  
> > Until then, the short answer is that the draft [1] discusses this 
> > condition in Section 4.7.
> > 
> > Thanks,
> > 
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, 
> > Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 01 Dec 2010 17:24:57 +0100

There is one scenario which comes to my mind is having a redundant server (B) which generally feeds to other type of traffic but it has capability to take SIP traffic.
(non SIP).

Now A, generally won't send to B but assuming any of existing servers are down(using HB or any other mechanim) and A detects this successfully. 
Hence A happily assumes it has an extra server (though its already overloaded) and diverts messages to B.
But B was already overloaded, so first X INVITEs fails and in response A gets to know B is overloaded. 
This X message failures could have been avoided if B could have passed some overload information
someway to A. 

Regards,
Rahul

----- Original Message -----
From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wednesday, December 1, 2010 5:13 pm
Subject: RE: [sip-overload] Open issue #1: algorithm agility
To: RahulSrivastava 71616 <[email-masked]>, "Gurbani, Vijay K (Vijay)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> It would seem to be useful only to tell SIP entities about 
> overload situations if you reasonably expect them to deliver SIP 
> requests to you in the timeframe that you are overloaded. That 
> equates very roughly to those SIP entities who are already 
> progressing SIP requests through you.
> 
> > 4.7 talks about only requests that are transmitted and will be 
> failed.>

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 1 Dec 2010 11:26:19 -0500

Letting A know before A sends a message to B (e.g., event package) would 
apply when Req 11 of 5390 is applicable:
"   REQ 11:  The mechanism should support servers that receive requests
      from a finite set of upstream elements, where the set of upstream
      elements is enumerable."

It would NOT make sense when Req 10 is applicable:
"   REQ 10:  The mechanism should support servers that receive requests
      from a large number of different upstream elements, where the set
      of upstream elements is not enumerable."

Janet

From:
"DRAGE, Keith (Keith)" <[email-masked]>
To:
RahulSrivastava 71616 <[email-masked]>, "Gurbani, Vijay K (Vijay)" 
<[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
12/01/2010 11:14 AM
Subject:
Re: [sip-overload] Open issue #1: algorithm agility

How does B know it is likely to receive calls from A? Presumably because A 
has used B before. 

It would seem to be useful only to tell SIP entities about overload 
situations if you reasonably expect them to deliver SIP requests to you in 
the timeframe that you are overloaded. That equates very roughly to those 
SIP entities who are already progressing SIP requests through you.

regards

Keith

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 01 Dec 2010 12:18:02 -0600

On 12/01/2010 09:59 AM, RahulSrivastava 71616 wrote:
> But my question is not related to 4.7. 4.7 talks about only requests
> that are transmitted and will be failed.
>
> A has not yet send B request. (This is the crucial point. You can
> assume a DNS reply has not given B's address yet).

Rahul: OK, I understand.  However ...

> But B is overloaded. How does B informs about its own status to A?

... in such a case, you

(i) either take a hit and have A run its retransmission timer before
  realizing that B is overloaded and from then on limit contacting B, or
(ii) if B anticipates heavy traffic, then the approach taken by the
  load-control-event-package [1] seems to be reasonable.

[1] http://tools.ietf.org/html/draft-shen-soc-load-control-event-package-00

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 3 Dec 2010 17:49:55 +0530

Vijay,
 
As we discussed in the interim meeting, the re-negotiation of algorithm will occurs when the system reboots or system upgrade or algorithm config/provisioning change. I mentioned out-of-dialog mechanism just to avoid algorithm negotiation per transaction or per dialog. out-of-dialog mechanism may result in some lightweight methods like OPTIONS. 
 
Having said that, I like to hear from you in detail how overload algorithm re-negotiated will be accommodated without out-of-dialog mechanism and without per transaction/dialog negotiation.

Thanks
Partha

From: Vijay K. Gurbani [mailto:[email-masked]]
Sent: Wed 12/1/2010 8:43 PM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [sip-overload] Open issue #1: algorithm agility

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 3 Dec 2010 18:01:12 +0530

Janet,
 
In case the system is designed for receiving the message from large number of upstream entity, it has to keep track of the algorithm and load which has to used with each of its upstream entity irrespective of whether the algorithm is negotiated out-of-band or in-band. So, out-of-band negotiation is not conflicting with Req 10 of RFC 5390.
 
Moreover, the current solution already rules out the possibility of being edge-proxy or edge-B2BUA.
 
Thanks
Partha

From: Janet P Gunn [mailto:[email-masked]]
Sent: Wed 12/1/2010 8:49 PM
To: Vijay K. Gurbani
Cc: Parthasarathi R (partr); [email-masked]; [email-masked]
Subject: Re: [sip-overload] Open issue #1: algorithm agility

Furthermore, relying on an advance, out-of-band, negotiation/notification of either "I support Overload Control" or "I support rate based overload control" might conflict with Req 10 of 5390: 
"REQ 10:  The mechanism should support servers that receive requests 
      from a large number of different upstream elements, where the set 
      of upstream elements is not enumerable." 

Janet 

From: 	"Vijay K. Gurbani" <[email-masked]> 
To: 	"Parthasarathi R (partr)" <[email-masked]> 
Cc: 	[email-masked] 
Date: 	12/01/2010 10:11 AM 
Subject: 	Re: [sip-overload] Open issue #1: algorithm agility	

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html <http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html> 

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/ <http://ect.bell-labs.com/who/vkg/> 
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload <https://www.ietf.org/mailman/listinfo/sip-overload>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 03 Dec 2010 08:37:30 -0600

On 12/03/2010 06:19 AM, Parthasarathi R (partr) wrote:
> Vijay, As we discussed in the interim meeting, the re-negotiation of
> algorithm will occurs when the system reboots or system upgrade or
> algorithm config/provisioning change. I mentioned out-of-dialog
> mechanism just to avoid algorithm negotiation per transaction or per
> dialog.

Partha: The interim meeting appear to indicate that there is
some value to re-negotiation.  However, it is not the case that the
re-negotiation will happen every transaction.  An abnormal
event will trigger a re-negotiation, and for the most part,
such an abnormal event that we talked about included a
system upgrade without taking the system out of service.

In the extreme case, a system reboot is indistinguishable from
a fresh start, so a renegotiation after a system reboot should
be handled without any problems.

> out-of-dialog mechanism may result in some lightweight
> methods like OPTIONS. Having said that, I like to hear from you in
> detail how overload algorithm re-negotiated will be accommodated
> without out-of-dialog mechanism and without per transaction/dialog
> negotiation.

Sure; I will put text into the next revision of the draft and we
can hash the nuances out then.

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 3 Dec 2010 21:22:02 +0530

Vijay,
 
It is fine with me..Let me wait for your next revision of draft.
 
Regards
Partha

Sent: Fri 12/3/2010 8:07 PM

Thanks,

- vijay