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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Nov 2010 17:37:50 -0600

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

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/

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 23 Nov 2010 14:31:39 +0100

One question:
 I have to return responses of these parameters in 100 Trying. 
100 Trying is decided by  lowest layer in SIP Stacks. 
And overload might be an application level parameter. 
(independent of SIP Stacks and decided based on non SIP logic).  

Will it be correct to pass this in INVITE-100 trying? 

By this I don't mean to suggest it can't be done. But won't this override the logic of 100 trying and clutter the logic.

Regards,
Rahul

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
Date: Tuesday, November 23, 2010 0:36 am
Subject: [sip-overload] Open issue #1: algorithm agility
To: "[email-masked]" <[email-masked]>

> supports additional algorithms beyond loss-based, it will include 
> thesein a comma-separated list in the "oc-algo" parameter, example:
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 23 Nov 2010 09:30:43 -0600

On 11/23/2010 07:31 AM, RahulSrivastava 71616 wrote:
> One question: I have to return responses of these parameters in 100
> Trying. 100 Trying is decided by  lowest layer in SIP Stacks. And
> overload might be an application level parameter. (independent of SIP
> Stacks and decided based on non SIP logic).
>
> By this I don't mean to suggest it can't be done. But won't this
> override the logic of 100 trying and clutter the logic.

Let's put it this way --- there is nothing in the draft that
precludes an implementation from inserting these parameters
in the 100, nor is there anything that mandates doing so.

In other words, if you want to put these in a 100, go for it.
If you don't, there'll be other 1xx-class messages going
back to the upstream SIP entity.

Ciao,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 23 Nov 2010 11:38:35 -0500

Vijay,

In principle this sounds reasonable.

I just want to make sure I am understanding correctly.

Under your scheme 
- oc-algo="loss,rate,window"
and
- oc-algo="rate,window"

both mean the same thing- it supports loss, rate, and window.

Janet

[email-masked] wrote on 11/22/2010 06:37:50 PM:

> [image removed] 
> 
> [sip-overload] Open issue #1: algorithm agility
> 
> Vijay K. Gurbani 
> 
> to:
> 
> [email-masked]
> 
> 11/22/2010 06:36 PM
> 
> Sent by:
> 
> [email-masked]
> 
> Folks:
> 
> [1] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00403.html

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 23 Nov 2010 10:43:09 -0600

> both mean the same thing- it supports loss, rate, and window.

Janet: Indeed.  Loss-based is the lowest common denominator
that all implementations implement.  I will flush out the details
in a follow-up draft, but did want to get this issue out before the
virtual interim meeting.

Thanks,

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 24 Nov 2010 05:51:59 +0100

Not only about inserting but upstream server needs to handle this if downstram server adds this.
Hence I won't like to handle this logic where extra response (100 trying) traverse till application layer and there overload control can be decided.
I'll prefer draft should clearly state olc information won't be passed in 100 trying. 
Please consider this comment.

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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 Nov 2010 08:21:57 -0600

> downstram server adds this.

Indeed so; and that is true regardless of whether the overload
control parameters are added in a 1xx or a non-1xx.

> Hence I won't like to handle this logic where extra response (100
> trying) traverse till application layer and there overload control
> can be decided. I'll prefer draft should clearly state olc
> information won't be passed in 100 trying.

I think the best we can do is to leave things as they are (i.e.,
have the draft talk in terms of "responses" instead of "1xx
and non-1xx responses.")

What happens if we do as you suggest and some implementation has
overload information by the time it generates a 100 and it would
like to send this to its upstream entity?  We would be unnaturally
inhibiting this implementation from sending the overload
information at the earliest convenience.

Thanks,

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 24 Nov 2010 15:46:54 +0100

Rahul -- Problem what I can see will be to handle this.
 Existing implementations 
(to what extent I know. ) might crib since they won't handle 100 TRYING at application level.

What this draft permits (though not mandates) is handling of overload informtion in 100 TRYING. 
It means an additional handling of messages for all success cases. (in 100 trying)

For me this is an perhaps overkill for a case like overload which happens once in a while and 
we are allowing one extra message processing always for sake of trying to be on time for worst case.

Further for messages like SUBSCRIBE/MESSAGE/REGISTER 100 trying is not sent all the time (unlike INVITE).

I'll like to see a 1xx/non-1xx excludes (100 trying) for overload information.

Regards,
Rahul

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
Date: Wednesday, November 24, 2010 3:20 pm
Subject: Re: [sip-overload] Open issue #1: algorithm agility
To: RahulSrivastava 71616 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> > Not only about inserting but upstream server needs to handle 
> this if
> > downstram server adds this.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 Nov 2010 09:04:47 -0600

On 11/24/2010 08:46 AM, RahulSrivastava 71616 wrote:
> Rahul -- Problem what I can see will be to handle this. Existing
> implementations (to what extent I know. ) might crib since they won't
> handle 100 TRYING at application level.
>
> What this draft permits (though not mandates) is handling of overload
> informtion in 100 TRYING. It means an additional handling of messages
> for all success cases. (in 100 trying)
>
> For me this is an perhaps overkill for a case like overload which
> happens once in a while and we are allowing one extra message
> processing always for sake of trying to be on time for worst case.
>

Ah, OK.  I think I see what you are trying to say.  Let me re-phrase
my understanding of your problem and make sure that we converge to
the same definition before we go about figuring how to create solution.

What you seem to be concerned about is that since 100 may be generated
at the transaction level, and consumed at the transaction level, sending
the overload control parameters in a 100 may not benefit the receiving
entity if it only processes the 100 at the transaction level (and not
send it to the TU).

Is that accurate?  Please confirm so we can go about figuring what to
do, if anything, to the draft to make the intent explicit.

Thanks,

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 24 Nov 2010 16:09:31 +0100

Exactly. 
Additionaly by allowing this information to be passed on in 100 Trying we are 
keeping it open for implementations to explicitly check all 100 Trying responses.

Regards,
Rahul

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
Date: Wednesday, November 24, 2010 4:03 pm
Subject: Re: [sip-overload] Open issue #1: algorithm agility
To: RahulSrivastava 71616 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> > implementations (to what extent I know. ) might crib since they 
> won't> handle 100 TRYING at application level.
> >
> > What this draft permits (though not mandates) is handling of 
> overload> informtion in 100 TRYING. It means an additional 
> handling of messages
> at the transaction level, and consumed at the transaction level, 
> sendingthe overload control parameters in a 100 may not benefit 
> the receiving

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 Nov 2010 10:03:31 -0600

On 11/24/2010 09:09 AM, RahulSrivastava 71616 wrote:
> Exactly. Additionaly by allowing this information to be passed on in
> 100 Trying we are keeping it open for implementations to explicitly
> check all 100 Trying responses.

Rahul: Thanks for your feedback.

I think making any assumptions about how a particular implementation
is architected and, well, implemented is probably not the right way
for us to move forward.

Clearly, the fact an upstream SIP entity inserts the "oc" parameter in
a request going downstream implies that the corresponding code has been
modified to handle overload control parameters.  Therefore, for all we
know, the modifications may have included passing up to the TU the
overload control parameters in a 100 response.

Just as clearly, the fact that the downstream SIP server modified the
"oc" parameter implies that the corresponding code has been changed to
handle overload control parameters.  And, for all we know, the changes
may have included the TU passing overload control information to the
transaction layer to be added in a 100.

Now, let's take the case that the upstream SIP entity's code has been
modified to get the overload control information from an incoming
100 as well as non-100 provisionals and of course, final responses.
If the downstream SIP server sends overload control information
in the 100, then we are golden.  If on the other hand, the downstream
server does not send overload control information in 100 and instead
sends it in a non-100 provisional or some other final response, then
the upstream SIP entity still behaves as expected (i.e., it will
trigger overload control on getting the non-100 provisional or
final response.)

Similarly, take the case that the upstream SIP entity's code has NOT
been modified to look for overload control information in a 100, but
has been modified to trigger overload control on non-100 provisionals
and final responses.  In that case, when the downstream SIP server
sends overload control in a 100, the upstream SIP entity does not do
anything, but when the downstream SIP server sends overload control
in a non-100 provisional and final responses, then overload control
is triggered.

In either of the above combinations, sending (or not sending) overload
in a 100 does not harm either of the entities and the protocol proceeds
as normal.  So therefore, mandating anything else appears to put us
in a presumptuous situation of figuring out how each SIP stack will
be modified, and unless we have a very good reason to do so, I think
we should simply stay away from making any assumptions about
implementations.

Thanks,

- vijay

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 24 Nov 2010 17:36:03 +0100

100 Trying is somewhat special.

It's prime purpose is to turn off retransmission mechanisms, so to me, it should be sent quickly and read quickly. Any thoughts that it is used to transfer data should therefore be dealt with very carefully. Currently the only thing it really carries apart from the mandatory header fields is the Date (i.e. debugging type information). By default, we should not do this.

Therefore I think we need to think very carefully about whether the insertion of the information here detracts from its prime purpose, e.g. in areas of "Does it make it take longer to send the 100 Trying?" and "Does it make it take longer to read the 100 Trying?". Indeed yes to either of these could make the overload situation worse if the retransmission kicks in as a result.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Wednesday, November 24, 2010 4:04 PM
> To: RahulSrivastava 71616
> Cc: [email-masked]
> I think making any assumptions about how a particular 
> implementation is architected and, well, implemented is 
> probably not the right way for us to move forward.
> 
> Clearly, the fact an upstream SIP entity inserts the "oc" 
> parameter in a request going downstream implies that the 
> corresponding code has been modified to handle overload 
> control parameters.  Therefore, for all we know, the 
> modifications may have included passing up to the TU the 
> Just as clearly, the fact that the downstream SIP server 
> modified the "oc" parameter implies that the corresponding 
> code has been changed to handle overload control parameters.  
> And, for all we know, the changes may have included the TU 
> passing overload control information to the transaction layer 
> to be added in a 100.
> 
> Now, let's take the case that the upstream SIP entity's code 
> has been modified to get the overload control information 
> from an incoming 100 as well as non-100 provisionals and of 
> course, final responses.
> If the downstream SIP server sends overload control 
> information in the 100, then we are golden.  If on the other 
> hand, the downstream server does not send overload control 
> information in 100 and instead sends it in a non-100 
> provisional or some other final response, then the upstream 
> SIP entity still behaves as expected (i.e., it will trigger 
> overload control on getting the non-100 provisional or final 
> response.)
> 
> Similarly, take the case that the upstream SIP entity's code 
> has NOT been modified to look for overload control 
> information in a 100, but has been modified to trigger 
> overload control on non-100 provisionals and final responses. 
>  In that case, when the downstream SIP server sends overload 
> control in a 100, the upstream SIP entity does not do 
> anything, but when the downstream SIP server sends overload 
> control in a non-100 provisional and final responses, then 
> overload control is triggered.
> 
> In either of the above combinations, sending (or not sending) 
> overload in a 100 does not harm either of the entities and 
> the protocol proceeds as normal.  So therefore, mandating 
> anything else appears to put us in a presumptuous situation 
> of figuring out how each SIP stack will be modified, and 
> unless we have a very good reason to do so, I think we should 
> simply stay away from making any assumptions about implementations.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Wed, 24 Nov 2010 17:42:13 +0100

Thanks for such detailed response! My comments inline:

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
Date: Wednesday, November 24, 2010 5:01 pm
Subject: Re: [sip-overload] Open issue #1: algorithm agility
To: RahulSrivastava 71616 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> is architected and, well, implemented is probably not the right way
Rahul -- Perfect. Agreed. 
But this draft changes the basic structure of SIP. 100 Trying is to convey requests have been recieved and UAC/PXY
should not retransmit the requests any further. 
Now after this implementers will be free to overload 100 Trying to convey an overload hence all 100 trying needs to be screened for this also.
100 trying was for indicating reciept of request and stopping retransmission but now this draft changes it to convey status of a device/node etc. 
This is a pretty big change I assume.
On the contrary any other response does involve a non SIP logic.

> parameter in
> a request going downstream implies that the corresponding code has 
> beenmodified to handle overload control parameters.  Therefore, 
> for all we
> in a 100 does not harm either of the entities and the protocol 
> proceedsas normal.  So therefore, mandating anything else appears 
> to put us

Rahul -- Unfortunatly staying way won't solve a problem. :-). We need to get our hands dirty sometimes.
 This draft is about overload of SIP. But adding 100 Trying would overload this signal to 
be propogated to the top most layer always even for success cases contradicts basic requirement for overload control mechanism 
(i.e it should not add consume pretty much resource). 
As you ave pointed out 100 Trying might be consumed by Transcation layer. (different implementation might differ).

Yes this argument assumes 100 Trying is consumed by Transaction level and to my mind this looks 
like a fair assumption for a use case like overload which doesn't occur always.

Consider the other way round:

1xx doesn't include 100 Trying. :
Request returns 18x indicating an overload. Depending on a pxy/UA this might be forwarded to upstream or not. 

What we loose here is a delay when 100 Trying could have told this data beforehand.
If device was already overloaded and can't handle the requests information could be returned in non 2xx response.

Seeing the pros and cons of both approaches hence I still prefer the exclusion of 100 Trying for overload.

Regards,
Rahul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 25 Nov 2010 06:19:04 +0530

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:

   ...

   SIP/2.0 100 Trying

Thoughts?

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 29 Nov 2010 17:08:55 -0500

I agree with Keith.

It is my understanding that the whole POINT of "100 Trying" was to keep it 
"lean and mean" so that  it would always get back to the sender VERY 
QUICKLY. 

 If you add processing at either end (ESPECIALLY when the processor may be 
overloaded) you kind of defeat the whole point.

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:
"DRAGE, Keith (Keith)" <[email-masked]>
To:
"Gurbani, Vijay K (Vijay)" <[email-masked]>, 
RahulSrivastava 71616 <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
11/24/2010 11:36 AM
Subject:
Re: [sip-overload] Open issue #1: algorithm agility

It's prime purpose is to turn off retransmission mechanisms, so to me, it 
should be sent quickly and read quickly. Any thoughts that it is used to 
transfer data should therefore be dealt with very carefully. Currently the 
only thing it really carries apart from the mandatory header fields is the 
Date (i.e. debugging type information). By default, we should not do this.

Therefore I think we need to think very carefully about whether the 
insertion of the information here detracts from its prime purpose, e.g. in 
areas of "Does it make it take longer to send the 100 Trying?" and "Does 
it make it take longer to read the 100 Trying?". Indeed yes to either of 
these could make the overload situation worse if the retransmission kicks 
in as a result.

regards

Keith

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 29 Nov 2010 17:20:29 -0500

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.

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

Folks:

   ...

   SIP/2.0 100 Trying

[1] 

Thoughts?

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 30 Nov 2010 07:52:13 +0530

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]]
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

 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, 

Thanks 
Partha 

Folks:

  ...

  SIP/2.0 100 Trying

[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: Janet P Gunn <[email-masked]>
Date: Mon, 29 Nov 2010 22:54:47 -0500

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

Janet.

From: 

Vijay, 

Thanks 
Partha 

  ...

  SIP/2.0 100 Trying

[1] 

Thoughts?

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 30 Nov 2010 11:38:25 +0530

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]] 
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

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

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. 

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. 

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 

Folks:

 ...

 SIP/2.0 100 Trying

[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: Janet P Gunn <[email-masked]>
Date: Tue, 30 Nov 2010 07:56:43 -0500

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

From:
11/30/2010 01:08 AM

Janet,

 
Thanks
Partha

From: 

Janet, 

  
  
Thanks 
Partha 

Janet.

From: 

Vijay, 

Thanks 
Partha 

 ...

 SIP/2.0 100 Trying

[1] 

Thoughts?

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 30 Nov 2010 19:56:03 +0530

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

Sent: Tuesday, November 30, 2010 6:27 PM

Janet

Date: 	11/30/2010 01:08 AM 

Janet, 

  
Thanks 
Partha 

Janet, 

 
 
Thanks 
Partha 

Janet.

Vijay, 

Thanks 
Partha 

Folks:

...

SIP/2.0 100 Trying

[1]

Thoughts?

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 30 Nov 2010 09:39:15 -0500

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:
11/30/2010 09:26 AM

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

Janet

From: 

Janet, 

  
Thanks 
Partha 

From: 

Janet, 

 
 
Thanks 
Partha 

Janet.

Vijay, 

Thanks 
Partha 

...

SIP/2.0 100 Trying

[1] 

Thoughts?

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 30 Nov 2010 13:21:57 -0600

On 11/24/2010 06:49 PM, Parthasarathi R (partr) wrote:
> 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.

Partha: Exactly.  I do not envision the algorithm to be negotiated per
transaction.  Instead, the canonical usage would be for A and B to
negotiate an algorithm when A *first* contacts B and for the algorithm
to stay static once negotiated.

You further write in a separate email message but in the same thread
that:
> transaction. The current solution is to pass the overload algorithm
> per transaction in "oc". IMO, the current proposal is less efficient

To reiterate: I do not envision changing the algorithm every
transaction.  Instead, when upstream entity A *first* contacts a
downstream server B, the algorithm is negotiated in the first
transaction.  I realize that connections between A and B may be
closed and re-opened, but this does not mean that the algorithm
will be re-negotiated on every transaction.

In a sense, which algorithm was chosen is state maintained
by A for the duration that it executes.  Implementations may choose
to save this state to persistent store such that if A is re-started,
it will consult the persistent store and use the previously
negotiated algorithm when sending requests to B.  However, this
is implementation-specific and I don't forsee going too much into
details about how to maintain this state in the draft.  I suspect
that it suffices to say that the upstream entity will continue
using the same algorithm once negotiated for the duration of the
time that the upstream entity serves traffic to the downstream
server.

We can word-smith this to make it read better and be unambiguous in
the draft later.

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 1 Dec 2010 10:28:12 +0530

Vijay,

It is good that we agree upon the overload algorithm negotiation for the
first time when the traffic starts. 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. Atleast, 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.

Thanks
Partha

----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 12:52 AM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [sip-overload] Open issue #1: algorithm agility

To reiterate: I do not envision changing the algorithm every
transaction.  Instead, when upstream entity A *first* contacts a
downstream server B, the algorithm is negotiated in the first
transaction.  I realize that connections between A and B may be closed
and re-opened, but this does not mean that the algorithm will be
re-negotiated on every transaction.

In a sense, which algorithm was chosen is state maintained by A for the
duration that it executes.  Implementations may choose to save this
state to persistent store such that if A is re-started, it will consult
the persistent store and use the previously negotiated algorithm when
sending requests to B.  However, this is implementation-specific and I
don't forsee going too much into details about how to maintain this
state in the draft.  I suspect that it suffices to say that the upstream
entity will continue using the same algorithm once negotiated for the
duration of the time that the upstream entity serves traffic to the
downstream server.

We can word-smith this to make it read better and be unambiguous in the
draft later.

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/