Re: [sip-overload] Question on draft-gurbani-soc-overload-control-01

[Janet P Gunn <[e-mail]>]

This is actually a good illustration of why "local policy" is needed.

In many networks, where there is no way of preventing the end user from 
inserting a Priority Header with any value she wants, it would be a BAD 
IDEA to use that header as a way of making load shedding decisions.  It 
would be an open invitation to a DoS attack.

But I can certainly imagine a tightly controlled "walled garden" network 
where there is some mechanism for making sure that "Priority = emergency" 
is only used when the destination  corresponds to an "emergency number" or 
to a  PSAP. In that case it might make sense to make a load shedding 
decisions based on that header.

The Overload Control mechanisms should specify how the overload 
information is transferred between  SIP nodes.  It should also specify 
what the result is in broad terms (.e.g., "cut back SIP messages  by 30%" 
or "cut back to 100 SIP messages per second".

But the SIP Overload Mechanism SHOULD NOT  specify which messages do or do 
not get included in the set of messages (whether "70%" or "100 messages 
per second) that are transmitted.

THAT part of the algorithm is, and needs to remain "local policy", where 
"local" refers to the Service Provider, or the administrative domain, or 
the network, etc.

In one network, it might be the local policy to simply randomly chose 
which messages to forward and which not to.

In another network, the local policy  might be made entirely based on 
message type (e.g., drop INVITES first, then Registers, then ...)

In Laura's network it might be based on the Priority Header=emergency.  Or 
it might be based on the "to" field corresponding to a PSAP.  Or it might 
be based on the (proposed) RPH namespace esnet 
(draft-ietf-ecrit-local-emergency-rph-namespace)

In Keith's network, it might be based on "don't drop messages with RPH 
namespace xyz as long as they are less than 30% of the total goodput.  If 
they exceed 30% of the goodput, then ignore that namespace until it drops 
below 30% of the goodput".

In a DoD network with MLPP-like behavior, it might be "first drop the 
messages associated with calls that are likely to be pre-empted anyway" 
(e.g., RPH dsn.routine)

In another network it might be based on specific values of "to" or "from".

In another network it might be based on the associated SDP (drop messages 
associated with high bandwidth before you drop messages associated with 
low bandwidth).

Requirement 13 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."

The key phrase is ""The mechanism MUST NOT DICTATE a specific algorithm 
for   prioritizing the processing of work ... such as not being dropped"

"specific value of RPH" and "emergency services" are just examples (key 
words "such as") and do not limit the range of things that can be used to 
prioritize requests.

If the network needs to use the full range of the 40+ DoD associated RPH 
namespaces, and all their priority values- that is OK, that is THAT 
NETWORK'S local policy.

The local policy that works for the US  DoD is probably not a local policy 
that works well for a US commercial Service Provider.  The local policy 
that works well for a US commercial service provider is probably not a 
local policy that works well for a government network in China.


Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.



From:
Laura Liess <[e-mail]>
To:
Janet P Gunn/USA/CSC@CSC, "'Laura Liess'" <[e-mail]>, 
<[e-mail]>
Cc:
<[e-mail]>, "'Vijay K. Gurbani'" <[e-mail]>
Date:
07/29/2010 09:07 AM
Subject:
AW: [sip-overload] Question on draft-gurbani-soc-overload-control-01



Janet, Keith,

I am aware of that. But I have seen vendors solution using this the 
priority header as a mark for emergency calls and not the RPH. It seems 
that 3261 is not to 100% clear about that.  " For example, it may be 
factored into decisions about call routing and acceptance."  I just would 
not like ECs to be dropped.  I think a clear statement in the overload 
spec about what happens with requests containing priority =emergency, one 
way or another, will help to avoid dropping ECs. 

Thanks a lot 
Laura
 
Von: Janet P Gunn [mailto:[e-mail]] 
Gesendet: Donnerstag, 29. Juli 2010 12:31
An: Laura Liess
Cc: [e-mail]; [e-mail]; 'Vijay K. 
Gurbani'
Betreff: Re: [sip-overload] Question on 
draft-gurbani-soc-overload-control-01
 

I would doubt it. 

IIRC the "Priority Header Field" only has meaning at the end points, and 
is not used by the intervening network.   This is, at least in part, 
because there are no provisions for  authentication with the Priority 
Header. 

That was why we had to develop RPH in the first place. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose. 


From: 
Laura Liess <[e-mail]> 
To: 
"'Vijay K. Gurbani'" <[e-mail]> 
Cc: 
[e-mail] 
Date: 
07/29/2010 05:24 AM 
Subject: 
[sip-overload] Question on draft-gurbani-soc-overload-control-01
 




Vijay, 
The  draft-gurbani-soc-overload-control-01 states in section 5.1: “A SIP 
server SHOULD honor a request containing the Resource-Priority header 
field RFC4412..” I suppose it is assumed that the same is valid for 
requests containing Priority header field set to “emergency”. Do you 
intend to add this to the draft?  
Thanks a lot 
Laura _______________________________________________
sip-overload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sip-overload