Subject: [sip-overload] minutes from SoC IETF78 Maastricht

From: Salvatore Loreto <[email-masked]>
Date: Sun, 01 Aug 2010 19:53:59 +0300

Hi there,

I have just uploaded the minutes from the SoC IETF78 meeting.
...are available at   http://www.ietf.org/proceedings/78/minutes/soc.html

Corrections are welcome.

(Many thanks to Paul Kyzavit and Spencer Dawkins for taking notes during 
the meeting)

cheers
/Sal

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 10 Aug 2010 16:07:10 -0400

As requested, I have put together some suggested text about "local policy" 
for prioritizing SIP messages subject to overload controls.  I start with 
some explanation before the suggested text.

The questions of “local policies for selecting SIP messages to drop” goes 
way beyond RPH.

Req 13  of RFC5390 says:
“The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  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.”

RPH is only “such as”.  There are many other potential markers.

Local policies are typically local to a particular Service Provider, 
network, domain, etc.  and related to their service offerings.  Within a 
given network, there may be some variations in policy at different SIP 
elements, based on the call flow, the capabilities of that element, or the 
network configuration
For instance the P-CSCF might have different local policy from the HSS, 
within the same overall policy.  There may also be SIP boxes in the 
network that do not support SOC, or only a very simplistic version.

RPH is only an EXAMPLE of the things that can be used for “local policy”.

Other SIP based possibilities include 
Message type(e.g., INVITE and REGISTER vs.  ACK, CANCEL or BYE)
Associated SDP (e.g., high bandwidth requests vs. low bandwidth requests, 
or a multiuser conference vs a single session)
Contents of the “To” header URI
Contents of the URN (e.g., sos (for Emergency Services) vs. counseling)
Contents of the “From” Header URI
The value of “Max Forwards” (e.g.,low values may indicate a request that 
is unlikely to succeed in the long run, and is a candidate for dropping)

Even when it comes to RPH, the way in which in influences the SIP Overload 
Control mechanism is a matter of local policy.

In a preemption based (MLPP like) network, an RPH (e.g. dsn.routine) that 
indicates that a session is likely to be preempted under congestion would 
be one of the first to be dropped, while one that could preempt everything 
else (e.g., dsn.flash-override) would not be dropped.

In a priority queuing based network, where only 1% of the sessions are 
expected to have RPH with a specific namespace (e.g., ets and wps) it 
might make sense to drop only SIP messages without those namespaces. 

But if the percentage could be higher, and/or there are economic and other 
 incentives to make sure the “high priority calls” don’t “take over” the 
network, there could be a more complicated local mechanism which limits 
the number of “high priority” calls or call requests.

It is even possible that non-SIP markings could be used as part of the 
local policy on which messages to drop, for instance DSCP.

Suggested text- 

For draft-ietf-soc-overload-design my suggested text for  sec 12 is 

12.  Message Prioritization

   Overload control can require a SIP server to prioritize messages and
   select messages that need to be rejected or redirected.  The
   selection is largely a matter of local policy of the SIP server, the 
overall network, and the services it provides.  As a general rule, SIP 
server should prioritize messages for ongoing
   sessions over messages that set up a new session.

While there are many factors which can affect the prioritization of SIP 
messages, 
the Resource-Priority header field [RFC4412] is a prime candidate for 
marking the prioritization of SIP messages.  Depending on the particular 
network and the services it offers, a particular namespace and priority 
value in the RPH could indicate 
 -a high priority request, which should be preserved if possible during 
overload, or
 -a low priority request, which should be dropped during overload
- a label which has no impact on message prioritization in this network

For draft-gurbani-soc-overload-control-01 my suggested text for sec 4.5

A SIP server compliant to this specification MUST honor 'oc'
   parameter values it receives from downstream neighbors.  The SIP
   server MUST NOT forward more messages to a SIP server than allowed by
   the current 'oc' and 'oc-port' parameter values from this server.

   When forwarding a SIP request, a SIP entity uses the SIP procedures
   of [RFC3263] to determine the next hop SIP server.  The procedures of
   [RFC3263] take as input a SIP URI, extract the domain portion of that
   URI for use as a lookup key, and query the Domain Name Service (DNS)
   to obtain an ordered set of one or more IP addresses with a port
   number and transport corresponding to each IP address in this set
   (the "Expected Output").

   After selecting a specific SIP server from the Expected Output, the
   SIP server MUST determine if it already has overload control
   parameter values for the server chosen from the Expected Output.  If
   the SIP server has a non-expired 'oc' parameter value for the server
   chosen from the Expected Output, and this chosen server had
   restricted throttling to a specific port (by setting the 'oc-port'
   parameter earlier), then the SIP server MUST determine if it can or
   cannot forward the current request within the current conditions.
The particular algorithm used to determine whether or not to forward a 
particular SIP message is a matter of local policy, and may take into 
account a variety of prioritization factors.  However, this local policy 
SHOULD generate the same number and rate of SIP messages as the default 
algorithm, which treats all messages as equal. 

   In the absence of a different local policy, the SIP Server SHOULD use 
the  following default algorithm to determine if it
   can forward the request.  The SIP server draws a random number
   between 1 and 100 for the current request.  If the random number is
   less than or equal to the 'oc' parameter value, the request is not
   forwarded.  Otherwise, the request is forwarded .  Any other algorithms 
that approximate
   the random number algorithm may be used as well.

end suggested text

My suggested text for sec 5.1

5.1.  Message Prioritization

   During an overload condition, a SIP server needs to prioritize
   messages and select messages that need to be rejected or redirected.
   While this selection is largely a matter of local policy, certain
   heuristics can be suggested.  One, during overload control, the SIP
   server should preserve existing dialogs as much as possible.  This
   suggests that mid-dialog requests MAY be given preferential
   treatment.  Similarly, requests that result in releasing resources
   (such as a BYE) MAY also be given preferential treatment.

   A SIP server SHOULD honor the local policy for prioritizing SIP 
messages, 
such as policies based on the content of the Resource-Priority
   header field RFC4412 [RFC4412], RPH.  Specific (namespace. value)  RPH 
contents may  indicate a high priority requests (to be preserved as much 
as 
possible during times of overload.  Or the RPH contents may indicate a low 

priority request (eligible to be dropped during times of overload).  Other 

indicators, such as the SOS URN indicating an Emergency request, may also 
be used for prioritization.

The local policy can be expected to combine both the message type and the 
prioritization markings.

end suggested text

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: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Aug 2010 16:47:35 -0400

Comment at end

Janet P Gunn wrote:

>    forwarded.  Otherwise, the request is forwarded .  Any other 
> algorithms that approximate

There is an ambiguity in the above, and in the draft itself, as to what 
the oc parameter value applies to.

    The 'oc' parameter value specifies the percentage by which the load
    forwarded to this SIP server should be reduced.

What is "load"? The proposed text starts out talking about "messages", 
and then switches over to talking about "requests". But if you are just 
talking about the cpu cost of parsing, then both requests and responses 
constitute load. (Load could also include the effort of parsing a body 
when it is present, so that messages with bodies would present more load 
than messages without bodies.)

Choosing to drop only requests, and not responses is a value judgment, 
just like deciding to drop dialog establishing requests and not 
in-dialog requests.

The "default algorithm" takes the number given to it and applies that to 
all requests and no responses, and ends up selecting some number of 
requests to be dropped. The new text says:

    this local policy SHOULD generate the same number and rate of SIP
    messages as the default algorithm, which treats all messages as
    equal.

Would a local policy that drops an equal number of messages, but selects 
only responses, be valid according to this? Analyzing the words 
themselves I think so, but practically I think not.

So, I think a fundamental decision must be made - is overload control 
only concerned with *requests*, and not *responses*? If so, then text 
needs to be changed in a number of places to make that unambiguous.

Doing that means that 50% of the message processing load is off the 
table. But its probably still the right thing to do, except when 
considering DoS attacks.

Sending just responses would be one way of mounting a DoS attack that 
this mechanism can't cope with. But I think people have already stated 
that some other mechanism is expected to be used for DoS.

	Thanks,
	Paul

---

From: Padma Valluri <[email-masked]>
Date: Wed, 11 Aug 2010 11:49:53 -0400

Janet,

Should there be an explicit statement saying even if the downstream neighbors don't support this specification (hence no oc value received), still the messages with RPH need to be considered for prioritization to the extent possible? The SIP server that is forwarding this request has implemented this specification, but not all its neighbors.

thanks,

Padma.

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.

[email-masked] wrote: -----

To: [email-masked]
From: Janet P Gunn/USA/CSC@CSC
Sent by: [email-masked]
Date: 08/10/2010 04:07PM
cc: [email-masked], Volker Hilt <[email-masked]>, Gonzalo Camarillo <[email-masked]>
Subject: [sip-overload] minutes from SOC IETF78 Maastricht- text on local policy

As requested, I have put together some suggested text about "local policy" for prioritizing SIP messages subject to overload controls.  I start with some explanation before the suggested text.

The questions of “local policies for selecting SIP messages to drop” goes way beyond RPH.

Req 13  of RFC5390 says:

Local policies are typically local to a particular Service Provider, network, domain, etc.  and related to their service offerings.  Within a given network, there may be some variations in policy at different SIP elements, based on the call flow, the capabilities of that element, or the network configuration
For instance the P-CSCF might have different local policy from the HSS, within the same overall policy.  There may also be SIP boxes in the network that do not support SOC, or only a very simplistic version.

Other SIP based possibilities include
Message type(e.g., INVITE and REGISTER vs.  ACK, CANCEL or BYE)
Associated SDP (e.g., high bandwidth requests vs. low bandwidth requests, or a multiuser conference vs a single session)
Contents of the “To” header URI
Contents of the URN (e.g., sos (for Emergency Services) vs. counseling)
Contents of the “From” Header URI
The value of “Max Forwards” (e.g.,low values may indicate a request that is unlikely to succeed in the long run, and is a candidate for dropping)

Even when it comes to RPH, the way in which in influences the SIP  Overload Control mechanism is a matter of local policy.

In a preemption based (MLPP like) network, an RPH (e.g. dsn.routine) that indicates that a session is likely to be preempted under congestion would be one of the first to be dropped, while one that could preempt everything else (e.g., dsn.flash-override) would not be dropped.

In a priority queuing based network, where only 1% of the sessions are expected to have RPH with a specific namespace (e.g., ets and wps) it might make sense to drop only SIP messages without those namespaces.

But if the percentage could be higher, and/or there are economic and other  incentives to make sure the “high priority calls” don’t “take over” the network, there could be a more complicated local mechanism which limits the number of “high priority” calls or call requests.

It is even possible that non-SIP markings could be used as part of the local policy on which messages to drop, for instance DSCP.

Suggested text-

Overload control can require a SIP server to prioritize messages and
select messages that need to be rejected or redirected.  The
selection is largely a matter of local policy of the SIP server, the overall network, and the services it provides.  As a general rule, SIP server should prioritize messages for ongoing
sessions over messages that set up a new session.

While there are many factors which can affect the prioritization of SIP messages,
the Resource-Priority header field [RFC4412] is a prime candidate for marking the prioritization of SIP messages.  Depending on the particular network and the services it offers, a particular namespace and priority value in the RPH could indicate
-a high priority request, which should be preserved if possible during overload, or
-a low priority request, which should be dropped during overload
- a label which has no impact on message prioritization in this network

The particular algorithm used to determine whether or not to forward a particular SIP message is a matter of local policy, and may take into account a variety of prioritization factors.  However, this local policy SHOULD generate the same number and rate of SIP messages as the default algorithm, which treats all messages as equal.

In the absence of a different local policy, the SIP Server SHOULD use the  following default algorithm to determine if it
can forward the request.  The SIP server draws a random number
between 1 and 100 for the current request.  If the random number is
less than or equal to the 'oc' parameter value, the request is not
forwarded.  Otherwise, the request is forwarded .  Any other algorithms that approximate
the random number algorithm may be used as well.

end suggested text

A SIP server SHOULD honor the local policy for prioritizing SIP messages,
such as policies based on the content of the Resource-Priority
header field RFC4412 [RFC4412], RPH.  Specific (namespace. value)  RPH
contents may  indicate a high priority requests (to be preserved as much as
possible during times of overload.  Or the RPH contents may indicate a low
priority request (eligible to be dropped during times of overload).  Other
indicators, such as the SOS URN indicating an Emergency request, may also
be used for prioritization.

The local policy can be expected to combine both the message type and the prioritization markings.

end suggested text

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. _______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Volker Hilt <[email-masked]>
Date: Wed, 11 Aug 2010 21:40:14 -0400

Paul,

overload controls should only be applied to requests and not to 
responses for a couple of reasons:
- responses cannot be rejected. They would have to be dropped, which 
would lead to a retransmission of the request+response pair. I.e., this 
will lead to even more load.
- the requests that triggered the response has already been processed. 
Dropping the response will waste the efforts that have been spent on 
processing requests.
- most importantly, by rejecting a request, a proxy gets rid of the 
request plus the associated response. I.e., a proxy can essentially get 
to a load of zero if it rejects all requests. No responses will be 
returned. As a consequence, even extreme overload can be handled by 
targeting requests only.

I will add Janet's text to the design consideration draft and clarify 
that overload should target requests only.

Thanks,

Volker

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Aug 2010 08:54:07 -0400

Volker,

> that overload should target requests only.

I wasn't trying to imply that overload control *should* apply to 
responses - only that the text was ambiguous about that. Hopefully these 
changes will clarify that.

However, if the actual overload problem is about processing messages 
(both requests and responses), and the oc mechanism only targets 
requests, then the algorithm for computing the the reduction amount will 
need to take that into account.

E.g. If I am receiving 1000 msgs/sec - 500 requests and 500 responses - 
and can only handle 800 msgs/sec, then I need a reduction of 200 
msgs/sec. So if the percentage reduction applies only to requests, then 
I will have to request a 40% reduction in requests, not 20%.

	Thanks,
	Paul

---

From: Volker Hilt <[email-masked]>
Date: Thu, 12 Aug 2010 09:15:30 -0400

> changes will clarify that.
Yes, these are good points!

> need to take that into account.
Yes.

> I will have to request a 40% reduction in requests, not 20%.
Instead of measuring the number of messages, a proxy generating the 
overload feedback should measure the number of requests and generate the 
feedback based on that. That way, no conversion is needed. In your 
example, a proxy with a capacity of 400 requests/s would measure that it 
is receiving 500 requests and can generate the appropriate feedback.

Thanks,

Volker