Subject: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 12 Jul 2010 17:48:14 -0500

Folks: I have released draft-gurbani-soc-overload control.  The
latest version (-01) can be accessed at [1], with diffs from
-00 available at [2].

The major changes in this version are as follows:

1) Two new overload control parameters have been added.

  oc-seq was added as a result of mailing list deliberation
  captured in [3].

  oc-port was added to support overload control destined for
  a single port on the downstream SIP server.  The rationale
  for this is in S4.2 of [1].

2) Three discrete open issues have been documented (please
  search for "OPEN ISSUE{1,2,3}".  Open issue 1 has been in the
  draft for a long time.

  Open issue 2 has been discussed in the mailing list (please
  see [4]).

  Open issue 3 was discussed during the interim and relates to
  prioritization.  Please see [5] for more information on it while
  reading that specific part of the draft.

3) Added a new section --- "Overview of operations".

4) I have made some editorial changes and updated the
  references accordingly.

It will be good to have some discussions on the newly added
material as well as the open issues before Maastricht.

[1] http://tools.ietf.org/html/draft-gurbani-soc-overload-control-01
[2] 
http://tools.ietf.org/rfcdiff?url2=draft-gurbani-soc-overload-control-01.txt
[3] http://www.ietf.org/mail-archive/web/sip-overload/ current/msg00250.html
[4] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00229.html
[5]  http://www.ietf.org/mail-archive/web/sip-overload/current/msg00272.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/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jul 2010 19:26:17 -0400

Vijay,

I'm trying to understand what a solution would look like to open issue 3 
about the relationship between the algorithm (SHOULD strength) in 4.5 
and the Prioritization of 5.1.

The algorithm is nice, because it doesn't require maintaining any 
history, or selecting a time window over which the reduction is to be 
accomplished. But as soon as you introduce prioritization, those nice 
properties go away.

ISTM it would be better to define an algorithm that first selects the 
messages subject to throttling, and then applies the oc algorithm only 
to those.

Also, I see nothing good coming of having the prioritization being a 
local policy. If it is to be policy at all, it needs to be the policy of 
the overloaded node, not of its neighbor.

I'm thinking that the messages subject to throttling would be:
- anything out of dialog request, including those that would establish
   a new dialog
- MESSAGE, INFO, NOTIFY, REFER
- any request not registered in IANA

Things that notably would *not* be throttled would be:
- responses
- reINVITE, reSUBSCRIBE, PRACK, UPDATE, BYE, CANCEL

Conceivably reINVITE and reSUBSCRIBE should also be filtered, since that 
is likely to result in the dialog going away, thus reducing load further.

This seems like it ought to work well for any *legitimate* overload.

It however might be a problem when the upstream neighbor is a proxy and 
the overload is a DoS attack. I think a typical proxy can only 
distinguish an in-dialog request by the presence of a to-tag, so an 
attacker can send lots of bogus in-dialog UPDATEs, PRACKs, or reINVITES 
and avoid this sort of filtering.

I don't have any good answer for that.

	Thanks,
	Paul

Vijay K. Gurbani wrote:
> [5]  
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00272.html
> 
> Thanks,
> 
> - vijay

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 14 Jul 2010 17:15:57 +0300

(as a participant)

Section 7 Design consideration, seems to me to be something more 
appropriate to have in the
"Design Consideration" draft then in this document that draft an actual 
solution mechanism.

more in line

/sal

> messages subject to throttling, and then applies the oc algorithm only
[Sal] that is an interesting point. The server that sends the feedback 
is also the one that knows
which kind of message should be subject to throttling.

> the overloaded node, not of its neighbor.
[Sal] well a local policy has it value, but it could be augmented using 
appropriate feedback.
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>    

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 14 Jul 2010 13:52:09 -0500

> and the Prioritization of 5.1.

Paul: Thank you for your comments.  More inline.

> accomplished. But as soon as you introduce prioritization, those nice

Precisely.

> messages subject to throttling, and then applies the oc algorithm only

If we take the tact that mid-dialogue messages are not dropped, then
it will help to have some idea of the probability distribution of
in-dialogue messages arriving at the upstream neighbour.  If the
probability of a message being in-dialogue is small, as I suspect
it will be, then we can limit the complexity of the algorithm.
However, if it is high, then no matter what we do, we will end up
in a situation where some mid-dialogue messages will have to be
dropped (consider, for instance, a high loss rate of 60% coupled
with a high probability of incoming messages being in-dialogue.
Some of these messages will have to be dropped.)

> the overloaded node, not of its neighbor.

By the same token, it is the neighbour that is altruistically
expending resources by shaping traffic towards the overloaded
node.  Consequently, we cannot burden the upstream neighbour node
with too much decision making least we detract it from servicing
other downstream nodes.

Also, pragmatically speaking, to get widespread adoption we should
keep the complexity of implementation on the upstream neighbour
rather low.

> This seems like it ought to work well for any *legitimate* overload.

Generally, yes, I agree.

> I don't have any good answer for that.

If the upstream neighbour is overloaded with a DoS attack, I am sure
that filtering messages for its downstream servers is probably low
on its priority list.  In other words, having the upstream neighbour
throttle messages does not make matters any worse in terms of
*it* being attacked assuming that the throttling algorithm itself
is lightweight.

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 14 Jul 2010 15:20:09 -0400

[email-masked] wrote on 07/14/2010 02:52:09 PM:

> Vijay K. Gurbani 
> to:
> Paul Kyzivat
...

> keep the complexity of implementation on the upstream neighbour
As someone with a vested interest in Req 13 
("...It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment, such as not being dropped, being given additional
      retransmission, or being processed ahead of others."),
I have a rather different perspective. 

The objective is to make sure that SIP messages with a specific RPH value 
(even INVITEs with that RPH value) get through, and are processed,  even 
when other SIP messages are being dropped due to overload. 

It is therefore essential that the "local policy" which exempts these 
messages from overload controls, be implemented at the upstream node. 

If the upstream  (possibly not yet overloaded itself) node doesn't exempt 
the messages with this RPH, then having a local policy to exempt them at 
the downstream (already overloaded)node doesn't do any good, because they 
will never (rarely) get there. 

Janet

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jul 2010 21:01:31 -0400

>> accomplished. But as soon as you introduce prioritization, those nice

There is little point in presenting an algorithm that is not useful in 
practice. ISTM that it is important to present a practical algorithm.

> in-dialogue messages arriving at the upstream neighbour.  If the

Clearly there is no one probability distribution that is applicable in 
all cases. So either the distribution must be learned on the fly, or 
else an algorithm that doesn't require such a distribution must be found.

> Some of these messages will have to be dropped.)

Yes, that is my point.

> with too much decision making least we detract it from servicing

True - but I think there are algorithms that are easy.
I think it will be much easier to apply a classification each message in 
isolation, and then your probabilistic drop algorithm to those of a 
suitable class, than it will be to track history of messages in order to 
prioritize based on the population of messages in some window.

> keep the complexity of implementation on the upstream neighbour

No argument. Of course that depends on your definition of "low".
IMO implementing an already specified algorithm (even if it is somewhat 
complex) is likely to be simpler than inventing a "new" algorithm for 
achieving the proper drop rate.

>> This seems like it ought to work well for any *legitimate* overload.

Do you agree that an algorithm of this sort would be relatively easy to 
implement? (IMO its at least as easy as the percentage drop algorithm.)

It is expensive if distinguishing in-dialog messages is done by keeping 
dialog state when it isn't otherwise needed. But I would not expect 
that. I would expect a transaction-stateful (or stateless) proxy to 
decide in-dialog by the presence of the to-tag.

> *it* being attacked assuming that the throttling algorithm itself

If the upstream neighbor is itself under DoS attack, then oc may get 
applied further upstream until it can manage.

Its also possible that there are a number of upstream neighbors, with 
adequate aggregate capacity for the DoS attack, while it is too much for 
the downstream node.

In any case that wasn't my point. My point was that the selection 
algorithm that works for legitimate overload may not work for DoS, and 
some other algorithm may be required. Perhaps that is out of scope for now?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jul 2010 21:07:16 -0400

I forgot a point I wanted to make. This is a revised version of my prior 
message.

ISTM that the downstream node can fine tune this to its observed load by 
adjusting the drop percentage. (I asked for 20% drop but I'm still 
getting too much, so increase to 25%.)

Yes, that is my point.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jul 2010 10:58:13 -0500

On 07/14/2010 08:07 PM, Paul Kyzivat wrote:
> There is little point in presenting an algorithm that is not useful
> in practice. ISTM that it is important to present a practical
> algorithm.

Paul: I was not suggesting that we use the algorithm currently
in the draft --- it is a holdover from previous incarnations
of the draft.  While its memoryless and randomness properties
make it fairly simple, its utility in its current form is
rather limited when we consider prioritizing messages.

> True - but I think there are algorithms that are easy. I think it
> will be much easier to apply a classification each message in
> suitable class, than it will be to track history of messages in order
> to prioritize based on the population of messages in some window.
[...]
> Do you agree that an algorithm of this sort would be relatively easy
> to implement? (IMO its at least as easy as the percentage drop
> algorithm.)

I am not so much worried about coming up with an algorithm; a
solution will be found.  It is specifying the bounds of the
solution that are of interest right now.

As far as I can see it, the algorithm must consider the following
bounds:

1) R-P header take precedence and must not be dropped during
  overload;
2) Out-of-dialogue messages --- which for this purpose we can
  define as messages that does not have a To tag --- get dropped
  under overload;
3) In-dialogue messages should not be dropped to the extent
  possible; i.e., depending on the arrival rate of in-dialogue
  messages and the loss rate preferred by the downstream server,
  some in-dialogue messages may have to be dropped.

[...]
> algorithm that works for legitimate overload may not work for DoS,
> and some other algorithm may be required. Perhaps that is out of
> scope for now?

I agree as well; I think it is reasonable to keep a DoS attack
distinct from overload.  In overload, the upstream server is working
in tandem with the downstream server to prevent congestion collapse.
In DoS, it could very well be the upstream server itself that is under
attack.

Thanks,

- vijay

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Jul 2010 18:09:24 +0200

A minor comment on your 1)

> 1) R-P header take precedence and must not be dropped during

It is not the R-P header field itself, but the algorithm by which I handle the R-P header field has a precedence. If that algorithm for example states that no more than 30% of network capacity can be used by that namespace, then at some point calls with valid Resource-Priority header fields will also be dumped, as they would also be if higher priority Resource-Priority header fields also existed.

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Thursday, July 15, 2010 4:58 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [sip-overload] 
> draft-gurbani-soc-overload-control-01 in the IETF archives
> 
> Paul: I was not suggesting that we use the algorithm 
> currently in the draft --- it is a holdover from previous 
> incarnations of the draft.  While its memoryless and 
> randomness properties make it fairly simple, its utility in 
> its current form is rather limited when we consider 
> prioritizing messages.
> 
> > True - but I think there are algorithms that are easy. I 
> think it will 
> > be much easier to apply a classification each message in isolation, 
> > and then your probabilistic drop algorithm to those of a suitable 
> > class, than it will be to track history of messages in order to 
> > some other algorithm may be required. Perhaps that is out 
> of scope for 
> > now?
> 
> I agree as well; I think it is reasonable to keep a DoS 
> attack distinct from overload.  In overload, the upstream 
> server is working in tandem with the downstream server to 
> prevent congestion collapse.
> In DoS, it could very well be the upstream server itself that 
> is under attack.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Jul 2010 13:18:52 -0400

> 1) R-P header take precedence and must not be dropped during

I don't know that much about R-P. My impression is that R-P should only 
be taken into consideration if the box handling the message has an R-P 
policy it is enforcing. If so, then whatever that policy is needs to be 
taken into consideration.

>  some in-dialogue messages may have to be dropped.

I'm not convinced of this as a general statement.
I am inclined to agree that the set of messages required to bring an 
early dialog to final dialog state are probably bad choices to drop. And 
BYE is one you *really* don't want to drop.

Beyond that its questionable. For instance, why not drop reinvites? And 
certainly INFO and NOTIFY seem good candidates that there may well be a 
lot of, if there are any.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jul 2010 13:06:06 -0500

On 07/15/2010 12:18 PM, Paul Kyzivat wrote:
>> messages and the loss rate preferred by the downstream server, some
>> in-dialogue messages may have to be dropped.
>

Then what do we do when the arrival rate of the mid-dialogue
requests is greater than the loss rate?  Send them all even
though the downstream server asked for a message reduction?

>  early dialog to final dialog state are probably bad choices to drop.

In general yes, but I don't think you are proposing that we
require the upstream server to maintain state so it can distinguish
a message that transitions an early dialogue to a final one, are you?

> And BYE is one you *really* don't want to drop.

That depends on the role of the downstream server.  If
it is a media terminating UAS of some sort, yes BYE will help.
But if it is a proxy, then sending it a BYE and asking it to
proxy it forward when it is overloaded is probably not too helpful.

> Beyond that its questionable. For instance, why not drop reinvites?
> And certainly INFO and NOTIFY seem good candidates that there may
> well be a lot of, if there are any.

I think the best we can do is to send in-dialogue messages as much
as the loss rate allows.  That's it.  If the arrival rate of in-
dialogue messages is higher than the loss rate, some of these
will get dropped.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jul 2010 13:15:12 -0500

On 07/15/2010 11:09 AM, DRAGE, Keith (Keith) wrote:
> It is not the R-P header field itself, but the algorithm by which I
> handle the R-P header field has a precedence. If that algorithm for
> example states that no more than 30% of network capacity can be used
> by that namespace, then at some point calls with valid
> Resource-Priority header fields will also be dumped, as they would
> also be if higher priority Resource-Priority header fields also
> existed.

Keith: Agreed.  However, outside of an emergency situation of some
sort, SIP messages with R-P header will be very sparse, right (at
least that is my understanding)?

In case of an emergency, where most messages arriving to the upstream
server contain an R-P header, then we are in the same situation as
the discussion on what to do when most messages arriving at the
upstream server are in-dialogue messages.  Some of these will be
dropped.  That said, I quickly admit that I am not an authority on
how the US GETS service or comparable European and Asian services
work, so someone else can better guide us on what to do when arrival
rate of messages with R-P header is greater than what can be sent
to the downstream server.

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 15 Jul 2010 14:14:44 -0400

[email-masked] wrote on 07/15/2010 11:58:13 AM:

> 07/15/2010 11:57 AM

WEELL- that is a step in the right direction, but it is a lot more 
complicated than that.

First of all, it is not the presence of ANY RPH that grants exemption from 
overload controls.  It is the combination of a PARTICULAR NAMESPACE and 
value, in conjunction with a "local policy" (local to that domain, or 
local to that device) to exempt  such messages (all or some) from overload 
controls.

Just as a for-instance, there are expected to be some networks in which 
EVERY SIP message (or at least every INVITE) will have RPH.  What will 
vary will be (possibly) the Namespace and (definitely) the priority value. 
 Obviously, in THAT network, it wouldn't make sense to exempt every SIP 
message with RPH from load control, you would be exempting ALL of them. It 
MIGHT make sense to exempt specific Namespace-Priority Value combinations.

On the other hand, there are expected to be other networks in which less 
than 1% of the SIP messages contain RPH (with one or two specific 
namespaces).  In THAT network, it may make sense to exempt all the 
messages with RPH, and those Namespaces, from overload controls. 

But even there, as Keith indicated, there may be a local policy that SIP 
Messages with that particular Namespace are exempt from overload control, 
unless/until the percent of such messages exceeds, say, 30% over some time 
interval.  In that case, the local policy would exempt the SIP messages 
with that RPH Namespace until the 30% threshold is crossed.  SIP messages 
with that RPH - Namespace would then  be subject to normal overload 
controls until it dropped back below the threshold (or a separate 
threshold).

There simply  needs to be the OPTION for the upstream node to apply its 
own particular local policy with regard to specific RPH Namespaces and 
values. 

The overall mechanism should NOT specify the local policy, but should not 
preclude it.  The earlier suggestions (that all decisions on what not to 
shed should be made by the downstream node) would preclude it.

Janet

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Jul 2010 14:45:13 -0400

Vijay,

That we are having such disagreements suggests to me that we have 
different perceptions about the impact and value of dropping one message 
vs. another. ISTM that requires some working out.

At a basic level, all messages are the same, so that it makes no 
difference which ones you drop, as long as the total number of messages 
delivered is reduced.

I guess the next level of consideration is one of policy - specifically 
regarding messages with R-P headers. That is one form of prioritization 
that is hard to argue with. (But it requires consistent policy among 
upstream and downstream nodes. If upstream favors messages with some 
R-P, but the overloaded node doesn't consider those special, then the 
effort has been counterproductive.)

After that it is a question of priorities. Is the goal to keep some 
*users* happy at the expense of others, vs. spreading the pain more 
equally? Or is it to *leverage* the rejected messages - preserving those 
(like BYE) that will help reduce future message load, and those that 
would likely just be retried if rejected, while dropping ones that are 
not likely to be retried.

	Thanks,
	Paul

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 15 Jul 2010 15:06:21 -0400

[email-masked] wrote on 07/15/2010 02:15:12 PM:

> DRAGE, Keith (Keith)
> 07/15/2010 02:13 PM

> least that is my understanding)?
If you are talking about the ets and wps namespaces in the "US Service 
Provider" networks, then yes, they will be sparse, even in an "emergency 
situation".

If you are talking about the disn namespace in the DISN network, then, no, 
they won't be sparse at all.

Janet

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Jul 2010 15:13:16 -0400

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Paul Kyzivat
> Sent: Thursday, July 15, 2010 2:45 PM
> To: Vijay K. Gurbani
> 

While that may be true in some ultra-simple systems, like a proxy, in practice I doubt that's generally true.  Lots of systems take more CPU resources for new INVITEs than they do for many other messages, for example, for a whole host of reasons.  Even in a legitimate "proxy", I bet out-of-dialog messages take more simply because of the routing/DNS piece.

But more importantly, I doubt whatever we do will succeed in the market place if in-dialog messages aren't given preference over out-of-dialog ones, at least for INVITE-based dialogs.  It's one thing to get a busy-tone or a call attempt delayed due to re-route; it's a completely different thing to have the call fail after ringing and pickup, or not cleared cleanly with a BYE.

> effort has been counterproductive.)

Yeah that's a toughy.  It would be lovely not to have to coordinate such, but I can see the case where it would lead to a very low goodput. :(

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Jul 2010 18:21:02 -0400

> On Behalf Of Vijay K. Gurbani
> Sent: Monday, July 12, 2010 6:48 PM
> To: [email-masked]
> 

It's probably a bit early to start nit-picking on the params in your draft, vs. the bigger issues of mechanism, but I can't help myself...
The draft has now grown to have 4 different params, which just seems to me to add more and more complication for little return...

1) You have an "oc_accept" param in the downstream request, to indicate the server sending the request supports overload control, and then the downstream server deleting it in the response to indicate *it* supports overload; meanwhile you have the downstream add another param "oc" which actually has the overload value.  Why not just do what the rfc3581 rport param does?  Have the upstream insert the "oc" param in its Via, and the downstream always sets it to some value in the response (with a value of 0 if not currently overloaded).  Voilà, one param less... and also simpler code too I bet.

2) You have an "oc-port" param to indicate if the overload info applies to the local ip+port, or just the ip.  Why do we _need_ this?  By that I don't mean what value does it have for indicating the overload only applies to the ip+port... I mean the opposite: why can't it ALWAYS be the case that it applies to only the ip+port?  Can we just stipulate it's always only ip+port and thus remove the need for the extra complication of this param?   What's broken or not working about the overload mechanism if we just always have it only apply to ip+port?  I ask because if it's "broken" that a server can't indicate the overload applies to the whole IP address, then how do we handle the case of a server having multiple IPs? (like an IPv4 and an IPv6, for example, or even just multiple IPv4's)  

3) You've added an "oc-seq" param for a response sequence number, so that a retransmitted response using a stale oc value does not overwrite a more recent oc value.  Currently the text (and ABNF) allow it to be either a increasing sequence number or a timestamp with millisecond precision.  Why make this more complicated by having two different forms/formats of sequencing?  Pick one. (and don't do it in milliseconds, since plenty of systems can send more than 1000 responses/second)  Also, the normative requirements for this in section 4.2 have to be cleaned up, for example implementations that are not capable of updating the 'oc' MUST NOT update the oc-seq in retransmissions (right now the text says "don't have to").  Another nit is the ABNF in section 6 does not actually have the oc-seq name.

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jul 2010 23:20:44 -0500

On 07/15/2010 05:21 PM, Hadriel Kaplan wrote:
> It's probably a bit early to start nit-picking on the params in your
> draft, vs. the bigger issues of mechanism, but I can't help myself...
>
Hadriel: No problem ... go for it ;-)

More inline.

> 1) You have an "oc_accept" param in the downstream request, to
> indicate the server sending the request supports overload control,
> and then the downstream server deleting it in the response to
> indicate *it* supports overload; meanwhile you have the downstream
> add another param "oc" which actually has the overload value.  Why
> not just do what the rfc3581 rport param does?  Have the upstream
> insert the "oc" param in its Via, and the downstream always sets it
> to some value in the response (with a value of 0 if not currently
> overloaded).  Voilà, one param less... and also simpler code too I
> bet.

This is a good idea.  I think it works.  Downstream servers that
do not support overload control will simply echo the "oc" parameter
in the topmost Via header.

> 2) You have an "oc-port" param to indicate if the overload info
> applies to the local ip+port, or just the ip.  Why do we _need_
> this? By that I don't mean what value does it have for indicating
> the overload only applies to the ip+port... I mean the opposite: why
> can't it ALWAYS be the case that it applies to only the ip+port?
> Can we just stipulate it's always only ip+port and thus remove the
> need for the extra complication of this param?

That works for me as well.

> 3) You've added an "oc-seq" param for a response sequence number, so
> that a retransmitted response using a stale oc value does not
> overwrite a more recent oc value.  Currently the text (and ABNF)
> allow it to be either a increasing sequence number or a timestamp
> with millisecond precision.  Why make this more complicated by
> having two different forms/formats of sequencing?  Pick one.

Well ... there is a subtle programming dependency in play here.
If we choose the "oc-seq" parameter to be an increasing sequence
number, then we are essentially dictating that multi-threaded
implementations serialize their operations so that different
threads generating the response don't inadvertently get the
same sequence number.

Using a timestamp, OTOH, has the nice property that each thread
can generate a timestamp without needing to enter a critical
section.

Allowing implementations to use any one of the above absolves
us from impacting the architecture of a specific implementation.

> (and don't do it in milliseconds, since plenty of systems can send
> more than 1000 responses/second)

If people thing that millisecond resolution is too coarse, we
could always go microseconds.

> Also, the normative requirements for this in section 4.2 have to be
> cleaned up, for example implementations that are not capable of
> updating the 'oc' MUST NOT update the oc-seq in retransmissions
> (right now the text says "don't have to").  Another nit is the ABNF
> in section 6 does not actually have the oc-seq name.

I will fix these in the next iteration.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jul 2010 23:32:27 -0500

> WEELL- that is a step in the right direction, but it is a lot more

Janet: Thank you for this information; it is very helpful.
Handling R-P header is turning out to be more complicated
than I originally thought.  Please see inline for more
comments.

> First of all, it is not the presence of ANY RPH that grants exemption
> from overload controls. It is the combination of a PARTICULAR NAMESPACE
> and value, in conjunction with a "local policy" (local to that domain,
> or local to that device) to exempt such messages (all or some) from
> overload controls.

Paul K. brought this up as well, and I think it is important: what
if the upstream node allowed a message with R-P and namespace based
on *it's* notion of importance, but the downstream (overloaded) server
does not share the same notion of exempting messages with the namespace
that was important to the upstream node?  Then all the work has been
done for naught.

> vary will be (possibly) the Namespace and (definitely) the priority
> value. Obviously, in THAT network, it wouldn't make sense to exempt
> every SIP message with RPH from load control, you would be exempting ALL
> of them. It MIGHT make sense to exempt specific Namespace-Priority Value
> combinations.

How does the upstream node know which namespace-priority combination is
held sacrosanct by the downstream server?

Any thoughts on this?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jul 2010 00:32:56 -0400

> us from impacting the architecture of a specific implementation.

does it really matter *what* it is, as long as it is monotonic 
increasing and has sufficient resolution to distinguish among messages?

All the numbers come from the same source, so just let it decide what to 
use. The upstream node doesn't need to care.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Jul 2010 23:48:33 -0500

> use. The upstream node doesn't need to care.

Precisely; allowing it to be whatever the implementation chooses
as long as it is increasing is all that matters.  The upstream node
only needs to recognize the increment in value.

I don't see how allowing a choice of a pure sequence number or
a timestamp-based one constricts us.  OTOH, I would think that
it allows existing implementations flexibility; they can use
whatever fits their software architecture.

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Jul 2010 09:46:36 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, July 16, 2010 12:33 AM
> To: Vijay K. Gurbani
> Cc: Hadriel Kaplan; [email-masked]
> 

Absolutely - I agree completely - unfortunately right now the upstream node *does* "need to care".  The upstream node needs to support receiving two different formats of incrementing numbers, which means more parsing work and two different value types to store or convert to a common type.  Don't make the upstream node do that work.  Make the downstream node encode it in one and only one format.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Jul 2010 10:01:25 -0400

> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Friday, July 16, 2010 12:21 AM
> To: Hadriel Kaplan
> 

Right that's what I assumed the reason for a timestamp was, but I didn't mean it couldn't be based on a timestamp - just that we should pick one encoding format. 

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Jul 2010 17:31:13 +0200

> How does the upstream node know which namespace-priority 
> combination is held sacrosanct by the downstream server?
> 
> Any thoughts on this?

Essentially by configuration and appropriate levels of security between nodes to prevent masquerading as a legitimate sender.

A service provide agrees to support a namespace and within the boundaries of contracted support, all nodes support that namespace. Essentially it is very similar to the RFC 3324/3325 trust domain concept. If the previous/next node is within my namespace "trust domain", then I trust the values that I receive from that node to be a valid use of that namespace. At the edge of the "trust domain" I either ignore them, or in some way validate that that sender is allowed to send them, e.g. for a UA sender by some sort of authentication or whatever.

If a service provider supports the namespace, then I believe all defined values within the namespace are supported. The sending UA still has to be authorized for the right to use them.

Different namespaces could conceivably be supported with different "trust domains".

Having determined that the received namespace is a legitimate usage, what that actually means in terms of priority is down to the contract of the service provider with the administration/government body or whatever. It is not defined in RFCs.

regards

Keith

> Sent: Friday, July 16, 2010 5:32 AM
> To: Janet P Gunn
> than I originally thought.  Please see inline for more comments.
> 
> > from overload controls. It is the combination of a PARTICULAR 
> > NAMESPACE and value, in conjunction with a "local policy" (local to 
> > that domain, or local to that device) to exempt such 
> messages (all or 
> > some) from overload controls.
> 
> Paul K. brought this up as well, and I think it is important: 
> what if the upstream node allowed a message with R-P and 
> namespace based on *it's* notion of importance, but the 
> downstream (overloaded) server does not share the same notion 
> of exempting messages with the namespace that was important 
> to the upstream node?  Then all the work has been done for naught.
> 
> > Just as a for-instance, there are expected to be some networks in 
> > which EVERY SIP message (or at least every INVITE) will 
> have RPH. What 
> > will vary will be (possibly) the Namespace and (definitely) the 
> > priority value. Obviously, in THAT network, it wouldn't 
> make sense to 
> > exempt every SIP message with RPH from load control, you would be 
> > exempting ALL of them. It MIGHT make sense to exempt specific 
> > Namespace-Priority Value combinations.
> 
> How does the upstream node know which namespace-priority 
> combination is held sacrosanct by the downstream server?
> 
> Any thoughts on this?
> 
> Thanks,
> 
> - vijay
> --

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Jul 2010 10:34:16 -0500

On 07/16/2010 09:01 AM, Hadriel Kaplan wrote:
>> Using a timestamp, OTOH, has the nice property that each thread can
>> generate a timestamp without needing to enter a critical section.
>>
>> Allowing implementations to use any one of the above absolves us
>> from impacting the architecture of a specific implementation.
>
> Right that's what I assumed the reason for a timestamp was, but I
> didn't mean it couldn't be based on a timestamp - just that we should
> pick one encoding format.

Hadriel: OK; in that case, I will go ahead and update the ABNF to
use a timestamp only instead of a pure sequence number.

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 16 Jul 2010 12:43:05 -0400

"Vijay K. Gurbani" <[email-masked]> wrote on 07/16/2010 12:32:27 AM:

> Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF 
archives
> Janet P Gunn
> 07/16/2010 12:30 AM
> Cc:
> sip-overload
NAMESPACE
> > Just as a for-instance, there are expected to be some networks in 
which
> held sacrosanct by the downstream server?

Any time you leave things to "local policy" you leave open the possibility 
of stupid, ineffective, not-well-thought-out, or even downright malicious 
local policy.  And even a seemingly well-thought-out local policy can have 
unintended consequences.

But in the "real world", I think it is safe to assume that the Service 
Provider has an incentive (financial, operational, political, public 
relations...) to use RPH in an effective way. 

If both upstream and downstream nodes are controlled by the same service 
provider, it would be ineffective to have 
-the upstream node ignore namespace Z, and  exempt namespace A, 
and have 
-the downstream node exempt namespace Z and ignore namespace A. 
It COULD happen (especially if someone fat fingered the configuration), 
but it shouldn't.

In general, the Service Provider will make sure that the upstream and 
downstream nodes are exempting the same namespace (or the same 
namespace-value combination.

In reality, what probably WILL sometimes happen (for a variety of reasons) 
is
- the upstream node ignores namespace A (or RPH) entirely and the 
downstream node exempts namespace A from overload controls
- the upstream node exempts namespace A from overload controls and the 
downstream node ignores namespace A (or RPH) entirely

This could because the functionality is in the process of being rolled 
out, or because that vendor never developed the functionality, or because 
the Service Provider believes that the network is engineered in such a way 
that it is not needed at that node.

In those cases it is unfortunate, but just one of those things we have to 
live with.  It is probably better than having both nodes ignore it.

The more interesting case is where 

Network A give priority to RPH namespace A, and ignores namespace B

Network B give priority to RPH namespace B, and ignores namespace A

Yes, then, near the interface, you could have some complications with the 
upstream node exempting messages the downstream node is going to dump, and 
vice versa.  But, like so many things, this would be addressed by the 
business relationships between the Service Providers running Network A and 
Network B.

Janet

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jul 2010 12:43:22 -0400

> use a timestamp only instead of a pure sequence number.

Looking at the abnf, I see:

  oc-seq = (1*DIGIT) / (1*DIGIT "." 1*DIGIT)

Are you proposing to change that?

The issue is not the decimal point - it is that the range of values 
isn't limited in any way, nor is a comparison rule provided.

I could infer that the intent is to treat the ones without a decimal as 
integers, and the ones with the decimal as floating point. But that 
isn't helpful without range and precision limits, so I can know if the 
floating point in my implementation is sufficient.

(Is 
cseq=99999999999999999999999999999999999999999999.9999999999999999999999999999999
valid?)

So I think that needs to be nailed down, else it will be necessary to 
use variable precision arithmetic to do the comparisons.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jul 2010 12:50:11 -0400

Thanks for the explanation Janet.
A related question:

IIRC, (and its highly likely I don't) there is likely no defined 
ordering between values from two different namespaces.

If that is so, what are the implications for deciding which of two 
messages to reject?

	Thanks,
	Paul

Janet P Gunn wrote:
> Any time you leave things to "local policy" you leave open the 
> possibility of stupid, ineffective, not-well-thought-out, or even 
> downright malicious local policy.  And even a seemingly well-thought-out 
> local policy can have unintended consequences.
> 
> In reality, what probably WILL sometimes happen (for a variety of 
> reasons) is
> out, or because that vendor never developed the functionality, or 
> because the Service Provider believes that the network is engineered in 
> such a way that it is not needed at that node.
> 
> In those cases it is unfortunate, but just one of those things we have 
> to live with.  It is probably better than having both nodes ignore it.
> 
> Yes, then, near the interface, you could have some complications with 
> the upstream node exempting messages the downstream node is going to 
> dump, and vice versa.  But, like so many things, this would be addressed 
> by the business relationships between the Service Providers running 
> Network A and Network B.
> 
> Janet
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 16 Jul 2010 13:19:00 -0400

Rather than my paraphrasing it -  best to go to section 8 of RFC4412 for a 
discussion of the relative ordering of multiple namespaces.

Janet

Paul Kyzivat <[email-masked]> wrote on 07/16/2010 12:50:11 PM:

> [image removed] 
archives
> 
> Paul Kyzivat 
> 
> to:
> 
> Janet P Gunn
> 
> 07/16/2010 12:50 PM
> 
> Cc:
> 
> "Vijay K. Gurbani", sip-overload
> 
> >  > > from overload controls. It is the combination of a 
PARTICULARNAMESPACE
which
> >  > > of them. It MIGHT make sense to exempt specific 
Namespace-Priority 
> > Value
combination is

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jul 2010 13:58:15 -0400

Janet P Gunn wrote:
> 
> 
> Rather than my paraphrasing it -  best to go to section 8 of RFC4412 for 
> a discussion of the relative ordering of multiple namespaces.

Well - that was easy. The following from 8.1 seems to cover most of this 
discussion:

    If an RP actor understands multiple namespaces, it MUST create a
    local total ordering across all resource values from these
    namespaces, maintaining the relative ordering within each namespace.
    It is RECOMMENDED that the same ordering be used across an
    administrative domain.  However, there is no requirement that such
    ordering be the same across all administrative domains.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 18 Jul 2010 19:33:18 -0500

[...]

Janet: Thanks for the information; it's very helpful.  More inline.

> by the business relationships between the Service Providers running

So in summary, handling R-P header messages requires some manner of
out-of-band (with respect to SIP overload signaling) method to
converge on which R-P namespace the upstream and downstream server
agree is important.  This convergence may be easy if the upstream
and downstream servers are owned by the same administrative entity,
but a bit more involved, though not impossible, otherwise.

Is this accurate?

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 18 Jul 2010 19:35:23 -0500

> Are you proposing to change that?

Paul: Yes, absolutely.  This conversation has helped figure
out what to do.

> use variable precision arithmetic to do the comparisons.

The next revision will contain a more precise ABNF and relevant
instructions to appropriately interpret the ABNF.

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Sun, 18 Jul 2010 21:41:30 -0400

If by "out of band" you mean "business arrangement", then yes.

archives
> 07/18/2010 08:31 PM

---

From: Volker Hilt <[email-masked]>
Date: Mon, 19 Jul 2010 11:21:04 +0200

For any feedback, it will be important that a SIP server can determine 
the outcome of setting the oc parameter to a certain value. For example, 
it should be able to expect that setting oc=30 will lead to a reduction 
in the number of requests by 30%. The semantics of the oc parameter 
should be well-defined and something that is clear and easy to measure 
(e.g., number of requests). The question is then how a server can select 
the messages to be dropped to implement the oc value.

For a SIP server, there are two categories of requests: 1) requests that 
are candidates for reduction and 2) requests that should not be dropped 
(except for catastrophic situations). The first category would contain 
out-of-dialog messages (e.g., new INVITEs, SUBSCRIBES, ...) whereas the 
second category would contain in-dialog requests, requests protected by 
RPH policies,... (along the lines of Vijay's notes).

A draft will need to provide clear guidelines about which requests fall 
into the first and which fall into second category. I'd expect some of 
these guidelines to be MUST strength. E.g., I can't think of a case 
where someone would discard mid-dialog messages before invites. There 
need to be local policies as well (e.g., for RPH).

Once the categories are set, a SIP server can determine fairly easily 
which fraction of requests it is processing falls into the first 
category and which falls into the second category. E.g., 40% may be 
eligible for reduction, 60% not.

The server can then convert the overall oc feedback value it has 
received to a value that only applies to category 1). E.g., if it has 
received oc=10 in the above example, it would use 10 / 40 * 100 = 25 on 
requests in category 1). I.e., it would discard 25% of the message in 
category 1 which leads to the desired overall reduction of 10%. Messages 
in category 2 remain untouched.

The server can use random discard as discussed earlier to achieve the 
25% reduction of messages in category 1).

In a catastrophic case when there are not enough messages in category 1 
a server can broaden the scope of category 1). This is possible since 
assigning messages to categories and measuring their fraction is 
completely local. As an alternative it might start targeting messages in 
category 2 as well. This is simpler but provides less control over 
message selection.

Thanks,

Volker  (as individual contributor)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2010 19:49:27 -0400

> the messages to be dropped to implement the oc value.

While it would be a big problem if there was no correlation between the 
requested reduction and the actual reduction, its not at all clear to me 
that perfect correlation is necessary.

In the real world, the requested percentage reduction is just a guess at 
how much will have the desired effect. Even if the reduction complies 
perfectly, and the future load is perfectly consistent with the past 
load, it might not have the desired effect, since not all messages will 
affect the recipient equally.

And also, the arriving load will not perfectly maintain the prior rate 
or other characteristics.

So I think there need only be a reasonable positive correlation. It will 
be a feedback system that adjusts things to a satisfactory value.

> (except for catastrophic situations).

agreed

> The first category would contain 

As I noted earlier, its far from clear what the criteria should be for 
sorting messages into categories 1 and 2. What you describe is one 
possibility. But what is the reason for that choice, vs. some other like 
the one I suggested a few days ago?

(I'm not suggesting mine is objectively better. Only that in the absence 
of any criteria its equally good.)

> need to be local policies as well (e.g., for RPH).

Suppose you have INVITE dialogs, and SUBSCRIBE dialogs. The subscribe 
dialogs each have a bunch of NOTIFY messages in them.

And assume that the dialogs are long lived, so that the NOTIFY messages 
dominate the traffic.

You could certainly make the case that it would be better to reject 
NOTIFY messages. Rejecting INVITES wouldn't help much at all, and 
rejecting out of dialog SUBSCRIBE messages wouldn't help much for a long 
time.

> eligible for reduction, 60% not.

Well, depends on what you mean by "fairly easily". I guess it would have 
to maintain historic arrival rate for each category, computed over some 
time interval, and apply the percentage reduction to that. But its 
possible that even 100% of category 1 won't be enough, in which case it 
will need to dip into category 2 anyway.

Finding a good interval over which to calculate the arrival rate could 
be tricky too. If its longer than the interval over which the oc value 
changes it can be unstable. But if its too short you won't get an 
accurate sample.

> category 2 as well. This is simpler but provides less control over 

Broadening the definition of category 1 requires that you already rate 
data for the new definition. But yes, its still doable. It just gets 
more complex quickly.

	Thanks,
	Paul

>>> [mailto:[email-masked]]
>> While that may be true in some ultra-simple systems, like a proxy, in 
>> practice I doubt that's generally true.  Lots of systems take more CPU 
>> resources for new INVITEs than they do for many other messages, for 
>> example, for a whole host of reasons.  Even in a legitimate "proxy", I 
>> bet out-of-dialog messages take more simply because of the routing/DNS 
>> piece.
>>
>> But more importantly, I doubt whatever we do will succeed in the 
>> market place if in-dialog messages aren't given preference over 
>> out-of-dialog ones, at least for INVITE-based dialogs.  It's one thing 
>> to get a busy-tone or a call attempt delayed due to re-route; it's a 
>> completely different thing to have the call fail after ringing and 
>> pickup, or not cleared cleanly with a BYE.
>>
>>
>> Yeah that's a toughy.  It would be lovely not to have to coordinate 
>> such, but I can see the case where it would lead to a very low 
>> goodput. :(
>>
>> -hadriel

---

From: Volker Hilt <[email-masked]>
Date: Tue, 20 Jul 2010 23:34:35 +0200

> that perfect correlation is necessary.
Yes, I don't think it will be possible to achieve perfect correlation. 
However, having both diverge too much will have an impact on the 
stability of the mechanism.

> how much will have the desired effect.

The requested percentage is the output of a control algorithm.

> Even if the reduction complies
Yes. There is also the round trip time that adds delay before feedback 
takes effect.

> be a feedback system that adjusts things to a satisfactory value.
I agree there will be noise and correlation won't be perfect. However, a 
low correlation will lead to poor performance.

> the one I suggested a few days ago?
My main point is that we only need 2 categories: request that are 
candidates for reduction and request that are not. No need for a more 
complicated priority order.

> of any criteria its equally good.)
I agree. Each server can set up local policies to determine which set is 
best for its specific deployment/implementation.

> rejecting out of dialog SUBSCRIBE messages wouldn't help much for a long
Yes, it might be reasonable to make INVITE, SUBSCRIBE and NOTIFY 
messages part of category 1. INVITE mid-dialog messages will probably 
still fall into the second category. In the end, it will be local policy 
to determine what is in each category.

> time interval, and apply the percentage reduction to that.

I think computing an arrival rate is fairly straight forward for a 
proxy. It would have to be weighted to give new values higher significance.

> But its
Yes. See below.

> data for the new definition. But yes, its still doable. It just gets
Yes, you'd have to collect data for the new category. You can start 
collecting the arrival rate for the broader category 1 at a lower 
threshold (or even all the time). I don't see the significant complexity 
this will add. If you want to keep things really simple, a proxy can 
simply start going after messages in category 2 if category 1 is exhausted.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2010 21:25:18 -0400

Without replying to individual points, I want to discuss "local policy" 
for the drop algorithm.

If there are to be varying policies, then ISTM the gold standard is for 
the upstream node to use the policy that the overloaded node considers 
would be best for it.

Then the question is: how would the upstream node know and be prepared 
to use  that policy?

The simple answer would be: because it has been configured by someone 
who knew that. The more complex answer is that the downstream node 
communicates the desired algorithm to the upstream node.

What seems entirely wrong to me is the upstream node employing some 
local policy that is not informed in any way of the needs/preferences of 
the overloaded node. A standardized algorithm would be better than that.

Configuring the local policy may work well in some environments. But 
mostly in homogeneous ones. In a multivendor environment, without any 
standard selection of policies to choose from there may be no suitable 
policy available and no way to match the available policies against the 
needs.

	Thanks,
	Paul

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 20 Jul 2010 21:41:13 -0400

> "[email-masked]"

I will go a step beyond that and say that both the upstream and downstream 
nodes should use the policy that is considered "best" for the entire 
system/network by the people/organization responsible for running it.

> the overloaded node. A standardized algorithm would be better than that.

Clearly.

Local policies need to be configured and deployed in an intelligent way to 
be useful.  But I think we need to assume that the organization running 
the network will configure the local policies in an effective way.

The fact that local policies COULD be configured stupidly doesn't mean 
that there needs to be a standard describing how to configure them 
non-stupidly.

> policy available and no way to match the available policies against the 
I don't think it is so much multi-vendor vs single vendor as intelligently 
managed.  In other networks, multivendor overload systems interoperate 
reasonably effectively.

Janet

---

From: Volker Hilt <[email-masked]>
Date: Wed, 21 Jul 2010 13:14:33 +0200

Paul,

it is the upstream neighbor that needs to make a decision about which 
messages to drop in an overload situation. This server is a legitimate 
server on the path of the messages it needs to drop and, therefore, can 
make valid decisions about which messages to drop.

If proxies are required to exchange dropping policies, things get 
complex very quickly. First, proxies would have to agree on a set of 
policies that are supported by the upstream and the downstream neighbor. 
E.g., which features of messages can be used to formulate policies 
(differentiate between message types, in/out-of-dialog messages, RPH, 
SDP bodies, ...?).

Then policies would have to be negotiated. There are lots of questions 
right there: when will this negotiation happen? When the first message 
is exchanged between two servers? At bootup time? Some time else? What 
if a server rejects submitted drop policies? Will that be the end of the 
communication between the two servers? Or trigger another round of 
policy negotiations? How will these policies be encoded?

And finally servers would have to support mechanisms for selecting 
packets that can implement these policies. These mechanisms need to be 
generic enough to support all the possible policies that can be encoded.

What would be the benefit of going through all this trouble?

Thanks,

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2010 12:10:47 -0400

> make valid decisions about which messages to drop.

It MAY make any dropping decision it wants.
If its dropping them because it is overloaded, then it can judge whether 
they are valid decisions based on its own criteria.
But when its dropping them for the benefit of its downstream neighbor, 
then whether the choices are valid ought to be judged based on the 
overloaded node's criteria.

In some cases they may natively have the same criteria. But I don't see 
how we can assume they always do.

> (differentiate between message types, in/out-of-dialog messages, RPH, 

Regardless of whether the policies are negotiated or are configured, I 
think there needs to be some agreement about the policies that are 
candidates for selection.

For instance, if the goal was to have a consistent policy across the 
enterprise, that might be hard to achieve with products from multiple 
vendors if they don't offer the same selection of policies.

In theory I suppose you might consider an enterprise wide policy that 
favors INVITE dialogs and their in-dialog messages over SUBSCRIBE 
dialogs and their related messages. But if you deployed that wholesale, 
it wouldn't work when you got to a cluster of servers that were solely 
engaged in handling presence, and so never see INVITEs.

Of course you could then configure a different policy for that cluster 
of servers.

But at boundaries where you have a full range of traffic types coming 
in, then routed to more specialized servers, you may need different 
algorithms depending on the destination - selected with the needs of the 
destination in mind.

> What would be the benefit of going through all this trouble?

While negotiating the policy *might* have value, that may not be 
necessary. All I said was that the dropping be done with the needs of 
the overloaded node in mind. That still might be configured.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Jul 2010 15:29:49 -0500

On 07/21/2010 11:10 AM, Paul Kyzivat wrote:
> of servers. [...]

Paul: I respectfully submit that we are attempting to design a perfect
system to the detriment of one that is good.  I understand your
motivation to explore the need and exact notion of varying policies,
so please do not misunderstand my intent here.

However, in the particular example above of a cluster of servers
that are solely engaged in handling presence, would not a better
solution be to have the end points implement some sort of
event notification throttling scheme a la Niemi et al [1]?  Why
try to solve this particular problem using general overload control?

The general policy honed your posting and subsequent discussions
appear to be:

1) R-P header with an agreed-upon (by the upstream and downstream
  server) namespace take precedence and must not be dropped during
  overload;
2) Out-of-dialogue messages --- which for this purpose we can
  define as messages that does not have a To tag --- get dropped
  under overload;
3) In-dialogue messages should not be dropped to the extent
  possible; i.e., depending on the arrival rate of in-dialogue
  messages and the loss rate preferred by the downstream server,
  some in-dialogue messages may have to be dropped.

No?

[1] http://tools.ietf.org/html/draft-ietf-sipcore-event-rate-control-04

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Wed, 21 Jul 2010 22:39:22 +0200

> overloaded node's criteria.
A server needs to drop messages because of overload. This can be 
overload in itself or overload in a downstream neighbor (if the server 
would not react, it is even possible that the overload of the neighbor 
eventually leads to overload of itself).

Main point is that the server needs to drop messages to deal keep the 
network afloat. I don't see the benefit of engaging in policy 
negotiations at that point. The local server can make decisions that are 
perfectly valid.

> candidates for selection.
A draft should make recommendations on selections policies that have 
proven to be useful.

> Of course you could then configure a different policy for that cluster
Yes.

> algorithms depending on the destination - selected with the needs of the
Yes, that would be useful.

> the overloaded node in mind. That still might be configured.
I think we are in agreement.

Thanks,

Volker (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 23 Jul 2010 16:05:30 +0530

Hi Volker,

I agree that dropping of the message or dialog or session in the neighboring entity is only the possible way to avoid overload control. The local policy in the neighbor alone will not solve the entire problem by receiving the number of messages as the number of SIP message is not related to dialog and session and it will not serve the purpose. The current SoC design (Sec 9 of  draft-ietf-soc-overload-design-00) assumes that SIP message is the only unit between two SIP hops. The current approach complicates the overload design in case of  B2BUA/UA. 

The design should not restrict unit and should be flexible. The unit shall be messages, transaction, dialog, or session. draft-jones-sip-overload-sce-00.txt is one of the example where session (SCE) is provided as a unit. It will be better in case the algorithm is designed without specific unit in mind. The unit shall be agreed upon between two entities in prior. As you mentioned in the earlier mail, the unit shall be agreed between two SIP Hops through Non-SIP or configuration mechanism. 

Thanks

Partha

________________________________

From: [email-masked] on behalf of Volker Hilt
Sent: Thu 7/22/2010 2:09 AM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [sip-overload] draft-gurbani-soc-overload-control-01 in the IETF archives

Yes.

Thanks,

Volker (as individual)

---

From: Volker Hilt <[email-masked]>
Date: Fri, 23 Jul 2010 14:24:19 +0200

Partha,

I'm worried about the complexity and possible instabilities we are 
introducing if the unit of feedback is subject to negotiations. What if 
there is no agreement? What if units are changed from requests to 
sessions at some point? The upstream neighbor would then have to reset 
all measurements. It would also need to support many measurements and 
method selection methods.

I think that specifying a common unit for feedback is beneficial. One 
that comes to mind is feedback based on requests.

Thanks,

Volker

On 7/23/2010 12:35 PM, Parthasarathi R (partr) wrote:
> Hi Volker,
>
> I agree that dropping of the message or dialog or session in the
> neighboring entity is only the possible way to avoid overload control.
> The local policy in the neighbor alone will not solve the entire problem
> by receiving the number of messages as the number of SIP message is not
> related to dialog and session and it will not serve the purpose. The
> current SoC design (Sec 9 of draft-ietf-soc-overload-design-00) assumes
> that SIP message is the only unit between two SIP hops. The current
> approach complicates the overload design in case of B2BUA/UA.
>
> The design should not restrict unit and should be flexible. The unit
> shall be messages, transaction, dialog, or session.
> draft-jones-sip-overload-sce-00.txt is one of the example where session
> (SCE) is provided as a unit. It will be better in case the algorithm is
> designed without specific unit in mind. The unit shall be agreed upon
> between two entities in prior. As you mentioned in the earlier mail, the
> unit shall be agreed between two SIP Hops through Non-SIP or
> configuration mechanism.
>
> Thanks
>
> Partha
>
> *From:* [email-masked] on behalf of Volker Hilt
> *Sent:* Thu 7/22/2010 2:09 AM
> *To:* Paul Kyzivat (pkyzivat)
> *Cc:* [email-masked]
> *Subject:* Re: [sip-overload] draft-gurbani-soc-overload-control-01 in
> the IETF archives
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jul 2010 09:18:29 -0400

ISTM we are just talking past one another on this point and not 
converging in any way. Perhaps some informal face-to-face time will help 
here.

	Thanks,
	Paul

Volker Hilt wrote:
>>  >>>>> So I think there need only be a reasonable positive 
>> correlation. It
>>  >>>>> will
>>  >>>>>> For a SIP server, there are two categories of requests: 1) 
>> requests
>>  >>>>>> that
>>  >>>>>> out-of-dialog messages (e.g., new INVITEs, SUBSCRIBES, ...) 
>> whereas
>>  >>>>>> the
>>  >>>>> possibility. But what is the reason for that choice, vs. some 
>> other
>>  >>>>> like
>>  >>>>>> A draft will need to provide clear guidelines about which 
>> requests
>>  >>>>>> fall
>>  >>>>> rejecting out of dialog SUBSCRIBE messages wouldn't help much 
>> for a
>>  >>>>> long
>>  >>>>> time.
>>  >>>>>
>>  >>>>> Well, depends on what you mean by "fairly easily". I guess it 
>> would
>>  >>>>> have
>>  >>>>>>> practice I doubt that's generally true. Lots of systems take 
>> more
>>  >>>>>>> CPU
>>  >>>>>>>> R-P, but the overloaded node doesn't consider those special, 
>> then
>>  >>>>>>>> the

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 23 Jul 2010 09:19:07 -0400

> negotiations at that point. The local server can make decisions that are

While each device/server/node has its own local overload control 
mechanism, no node should be dropping traffic "for the benefit of" a 
particular node (itself, upstream, or downstream). 

Any traffic dropping should be intended for "the benefit of" the 
network/system/service.

It is my understanding that, in 5390, "local policy" usually means "local 
to this network/system/service, rather than "local to each node". 
Obviously, each individual node may have a different mechanism.  But all 
the nodes in the network/system/service should contribute to the local 
network/system/service policy.

Janet

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jul 2010 09:37:24 -0400

> Any traffic dropping should be intended for "the benefit of" the 

I doubt there is real disagreement over intent here - only words.
And maybe we have been sloppy about the words.

At least in my case, when talking about oc algorithms, I have been using 
the word "drop" to mean "refrain from sending this message to this 
particular destination". If there are alternative destinations for this 
message, then one or more of them may be tried (each subject to another 
oc algorithm test.) And even if there are no other eligible candidates, 
the request isn't really *dropped* since an error response will 
presumably be sent.

In the context of oc, this certainly *is* being done at the behest of 
(and hence for the benefit of) the downstream node.

Certainly it is a goal that effect of the overload algorithms, applied 
at individual points in the network, will benefit the 
network/system/service as a whole. But the algorithms under discussion 
only consider local information.

	Thanks,
	Paul

---

From: Volker Hilt <[email-masked]>
Date: Fri, 23 Jul 2010 16:39:50 +0200

I agree.

Volker

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Jul 2010 07:50:41 -0400

This topic is similar to one that has been raised about draft-jones-sip-overload-sce, about indicating overload of audio vs. video DSPs (ie, wanting to reject video but not audio, or vice-versa).

I think the overload work in general is really about *overload*; not CAC or session constraints or circuits available, and not INVITE vs. SUBSCRIBE vs. MESSAGE.  In other words, just because you're out of DSPs or circuits does not mean you're overloaded.  You're overloaded when you can't physically process SIP messages.  

What we're really talking about is message-processing-resource overload, and that's ALL.  Typically this would be CPU, but it could be memory too for memory-constrained cases.

Why?  Because if a device can still process SIP messages, then it can locally make the policy decision you guys are worried about to begin with.  There's no problem to solve for that case.  The problem we need to solve is actual SIP message processing overload.

The only "policy" issues we have to worry about, then, are (1) how to deal with RPH and (2) in-dialog vs. out-of-dialog messages.  

-hadriel

> Sent: Wednesday, July 21, 2010 12:11 PM

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Jul 2010 14:50:17 -0400

Hadriel,

I think it's important to solve two kinds of overload issues:
1) Where the SIP server is approaching a point where it is incapable of even responding to messages
2) Where a SIP server is unable to accept new sessions

The fist is typically an issue exhibited by devices like SIP proxies, especially stateless proxies where any one of several alternative devices may equally handle the next message that is transmitted by a neighboring device.

The second issue is one exhibited by stateful SIP proxies, SBCs, GWs, etc. and it is a problem that needs to be solved.  You're correct that if the device is able to respond that the entity sending the request can select an alternative device.  However, this is nonetheless a form of overload that has a negative impact on a session, especially the establishment time.

The SCE draft actually tries to target both (1) and (2), though it's primarily intended for use with stateful entities since it reports the ability of a SIP server to handle the traffic related to a new session based on the resources consumed by existing sessions.

Are you saying that the SOC WG will only consider overload issues related to (1)?  And, more specifically, is this primarily aimed at stateless entities?

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 24 Jul 2010 16:37:10 -0400

Yes, I'm saying SOC should only work on overload control.  I don't think that's an issue of stateless vs stateful devices - I think all type of SIP devices have a message processing overload problem.

I think anything more clever than that is doomed.  SBCs, proxies, GW's, etc. don't just run out of circuits/session-capacity in a way that's really applicable to this work - sure some are strictly 1:1 in-this-port-out-that-port type box, but most have their own routing and decision processes; they decide on a call-by-call basis what next-hop to send it to, and if there are circuits/capacity left to that next-hop.  There's no way they could signal which type of messages to reject in the future without exchanging routing tables, local policies, etc.  Every time they send back an indication, they'd have to indicate which trunk-group, or which number range, or which codecs, or which target domains, or any number of variables that make it decide to send a message to that next-hop.  How would that work?

BTW, I don't see the draft-jones-sip-overload-sce as being intricately tied to that "out-of-circuits" model... is it?  To me the other new things in it were also (1) use of the OPTIONS, and (2) the idea of sending remaining capacity instead of a throttle percent.

-hadriel

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Saturday, July 24, 2010 2:50 PM
> To: Hadriel Kaplan
> 
> Hadriel,
> 
> The fist is typically an issue exhibited by devices like SIP proxies,
> especially stateless proxies where any one of several alternative devices
> may equally handle the next message that is transmitted by a neighboring
> device.
> 
> The second issue is one exhibited by stateful SIP proxies, SBCs, GWs, etc.
> and it is a problem that needs to be solved.  You're correct that if the
> device is able to respond that the entity sending the request can select
> an alternative device.  However, this is nonetheless a form of overload
> that has a negative impact on a session, especially the establishment time.
> 
> The SCE draft actually tries to target both (1) and (2), though it's
> primarily intended for use with stateful entities since it reports the
> ability of a SIP server to handle the traffic related to a new session
> based on the resources consumed by existing sessions.
> 
> Are you saying that the SOC WG will only consider overload issues related
> to (1)?  And, more specifically, is this primarily aimed at stateless
> entities?
> 
> Paul
> 
> > This topic is similar to one that has been raised about draft-jones-sip-
> overload-sce, about indicating overload of audio vs. video DSPs (ie,
> wanting to reject video but not audio, or vice-versa).
> >
> > I think the overload work in general is really about *overload*; not CAC
> or session constraints or circuits available, and not INVITE vs. SUBSCRIBE
> vs. MESSAGE.  In other words, just because you're out of DSPs or circuits
> does not mean you're overloaded.  You're overloaded when you can't
> physically process SIP messages.
> >
> > What we're really talking about is message-processing-resource overload,
> and that's ALL.  Typically this would be CPU, but it could be memory too
> for memory-constrained cases.
> >
> > Why?  Because if a device can still process SIP messages, then it can
> locally make the policy decision you guys are worried about to begin with.
> There's no problem to solve for that case.  The problem we need to solve
> is actual SIP message processing overload.
> >
> > The only "policy" issues we have to worry about, then, are (1) how to
> deal with RPH and (2) in-dialog vs. out-of-dialog messages.
> >
> > -hadriel
> >
> >
> >> Subject: Re: [sip-overload] draft-gurbani-soc-overload-control-01 in
> the
> >> IETF archives
> >>

---

From: Janet P Gunn <[email-masked]>
Date: Sat, 24 Jul 2010 17:13:17 -0400

I agree that 1) and 2) are both important issues to solve.

But only 1) comes under the scope of SOC.

Janet

(Didn't we just go through this a month or so ago?)

> Paul E. Jones

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sun, 25 Jul 2010 13:27:11 +0530

Hadriel,

In case the SIP message could not be processed, then it is congestion
collapse.  When the system is overloaded, The system has to process SIP
message (Parse) and response back with 503 response. This parsing and
forming response involve CPU and memory. 

I agree that message-processing-resource overload is the only issue, the
local policy will solve. I thought of mentioning congestion collapse
avoiding crazy SIP overload handling just for illustration:

1) In case 80% or 85% of CPU utilization is reached, close the listening
SIP port in the system by which CPU utilization will come down soon and
open the SIP port when the system will be able to handle normal data.
The neighbor will get ICMP port unreachable and let the neighbor decide
the routing policy based on its design. There is no need of SIP protocol
communication. 

2) In case of memory utilization is reaching the threshold limit of 90%,
parse the first character to identify whether incoming SIP message is
request or response. The integer indicates that it is response. Process
only response message and discard request message parsing until the
memory utilization reaching the comfortable level in the system. Here
the request will be retransmitted or re-routed by neighbor according to
its policy.

By the above mechanism, the system will never reach the state called as
"congestion collapse", the system will perform in its maximum capacity
by properly using the upper threshold limit of CPU and memory but the
overall user/network experience will be bad. 

IMO, the feedback between two SIP entity is required to achieve the
maximum throughput between systems, provide the better solution for the
network, maximum utilization of resource in all the network elements
rather than just avoiding congestion collapse in the particular system.
Please let me know your opinion on the same and we will discuss in
face-to-face meeting for more thoughts.

Thanks
Partha

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Saturday, July 24, 2010 5:21 PM
To: Paul Kyzivat (pkyzivat); Volker Hilt
Cc: [email-masked]
Subject: [sip-overload] Overload policies (was:
draft-gurbani-soc-overload-control-01 in the IETF archives)

This topic is similar to one that has been raised about
draft-jones-sip-overload-sce, about indicating overload of audio vs.
video DSPs (ie, wanting to reject video but not audio, or vice-versa).

I think the overload work in general is really about *overload*; not CAC
or session constraints or circuits available, and not INVITE vs.
SUBSCRIBE vs. MESSAGE.  In other words, just because you're out of DSPs
or circuits does not mean you're overloaded.  You're overloaded when you
can't physically process SIP messages.  

Why?  Because if a device can still process SIP messages, then it can
locally make the policy decision you guys are worried about to begin
with.  There's no problem to solve for that case.  The problem we need
to solve is actual SIP message processing overload.

-hadriel

> dialogs and their related messages. But if you deployed that 
> wholesale, it wouldn't work when you got to a cluster of servers that 
> were solely engaged in handling presence, and so never see INVITEs.
> 

> algorithms depending on the destination - selected with the needs of 
> the destination in mind.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 25 Jul 2010 06:07:11 -0400

Hadriel,

SCE is not tied to "out-of-circuits", per se, but there are similarities 
in that it measures capacity of a variety of resources (whatever those 
resources might be).  As I mentioned, the aim with SCE was to address 
both (1) and (2), primarily for SIP servers that maintain session state 
(e.g., stateful proxies, SBCs, or other).

An SBC, for example, should not return a 503 in response to a message 
pertaining to an existing session.  That effectively breaks the 
session.  So, we want to monitor the stateful devices to ensure, as much 
as possible, that we never get to a point where it is unable to handle 
the message exchanges related to established sessions.  SCE would enable 
SBCs to better inform peers about available capacity so that those peers 
will not attempt to establish new sessions with SBCs that are nearly out 
of capacity.

SCE could be used by stateless proxies, but SCE would likely not serve 
as a good solution for stateless SIP proxies where most of the traffic 
has nothing to do with a session (e.g., routing messages related to 
presence).  For those kinds of message exchange on stateless entities, 
something else is needed (e.g., the percentage-based throttling 
proposal).  An alternative for stateless devices might even be a 
"message capacity estimate", though I think the end result would 
effectively look like the current soc-overload-control draft.  I like 
the idea in soc-overload-control and think it's a reasonable approach, 
especially for stateless devices.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 25 Jul 2010 06:17:44 -0400

Understood.  But, I personally think that (2) is an issue that needs 
to be addressed.  As SIP networks grow and as there are more SIP peering 
points, we will see longer delays in session establishment.  The reason 
is simply that, unless we over-provision the network, we will see an 
increased number of 5xx responses at peering points and gateways.  I'm 
surprised this issue hasn't already caused a few operators to get upset.

Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 25 Jul 2010 20:38:16 -0500

On 07/25/2010 02:57 AM, Parthasarathi R (partr) wrote:
[...]
> overall user/network experience will be bad.

Partha: IIUC, (1) above will cause oscillation (see S5.3 of rfc5390 for
an explanation.)  In addition, it has the insidious side effect
with responses arriving at the listening port (many systems,
especially those using UDP, simply arrange for responses to arrive
on the listening port as well.)  If this port is closed, then more
problems may occur.

Regarding (2), this may work for shorter SIP messages carried entirely
in a UDP datagram, but will not be as efficient for SIP messages
over a stream-oriented transport.  Here, one would still need to
parse to determine message boundaries, etc.

Thanks,

- vijay

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 26 Jul 2010 11:41:44 +0530

Hi Vijay,

I mentioned below two mechanisms to show how badly the system shall be
designed just to avoid only congestion collapse in the system. I'm
trying to say that avoiding congestion collapse alone should not be the
motive for SIP overload mechanism. 

For the mechanism 1, The oscillation occurs only in case of load
balancing deployment with less number of servers as mentioned in Para 2
of Sec 5.3 and also, the oscillation will not lead to congestion
collapse of the system  but leads to bad performance of the entire
network as I mentioned in the earlier mail. IMO, The oscillation is just
one of the issue during SIP overload. The dialog is established with one
server, then routing of forthcoming request is impossible to another
servers as other servers will not have the existing dialog related
information. 

The aim of the SIP overload solution has to utility the maximum
resources in all the network entities and provide more throughput even
during the overload in one or more SIP network entities.

Thanks
Partha
-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Monday, July 26, 2010 7:08 AM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [sip-overload] Overload policies

> I agree that message-processing-resource overload is the only issue, 
> the local policy will solve. I thought of mentioning congestion 
> collapse avoiding crazy SIP overload handling just for illustration:
>
> 1) In case 80% or 85% of CPU utilization is reached, close the 
> listening SIP port in the system by which CPU utilization will come 
> down soon and open the SIP port when the system will be able to handle
normal data.
> The neighbor will get ICMP port unreachable and let the neighbor 
> decide the routing policy based on its design. There is no need of SIP

> protocol communication.
>
> 2) In case of memory utilization is reaching the threshold limit of 
> 90%, parse the first character to identify whether incoming SIP 
> message is request or response. The integer indicates that it is 
> response. Process only response message and discard request message 
> parsing until the memory utilization reaching the comfortable level in

> the system. Here the request will be retransmitted or re-routed by 
> neighbor according to its policy.
>
> By the above mechanism, the system will never reach the state called 
> as "congestion collapse", the system will perform in its maximum 
> capacity by properly using the upper threshold limit of CPU and memory

> but the overall user/network experience will be bad.

Partha: IIUC, (1) above will cause oscillation (see S5.3 of rfc5390 for
an explanation.)  In addition, it has the insidious side effect with
responses arriving at the listening port (many systems, especially those
using UDP, simply arrange for responses to arrive on the listening port
as well.)  If this port is closed, then more problems may occur.

Regarding (2), this may work for shorter SIP messages carried entirely
in a UDP datagram, but will not be as efficient for SIP messages over a
stream-oriented transport.  Here, one would still need to parse to
determine message boundaries, etc.

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: Victor Pascual Avila <[email-masked]>
Date: Mon, 26 Jul 2010 13:02:47 +0200

Overloading the ability to handle communication sessions is different
than overloading the ability to handle messages. I think that both
should be addressed by the IETF.

-Victor

On Sun, Jul 25, 2010 at 12:17 PM, Paul E. Jones <[email-masked]> wrote:
> Understood.  But, I personally think that (2) is an issue that needs to be
> addressed.  As SIP networks grow and as there are more SIP peering points,
> we will see longer delays in session establishment.  The reason is simply
> that, unless we over-provision the network, we will see an increased number
> of 5xx responses at peering points and gateways.  I'm surprised this issue
> hasn't already caused a few operators to get upset.
>
> Paul
>

-- 
Victor Pascual Ávila