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

["DRAGE, Keith (Keith)" <[e-mail]>]

I do agree with Janet that local policy may look at this (I also agree with her other comments).

However I do not want to call out the Priority header explicitly.

I also do not know of any document that explicitly calls out this header as a means of identifying an emergency call. For example in 3GPP it is intentionally not mentioned, and the Request-URI contents or Route header field contents are currently the only correct marker.

If you need an explicit marker for emergency call priority then the new namespace work proposed by James Polk is the direction to go in. That integrates it with other priority mechanisms your network may need to support and provides a single level evaluation of priority.

regards

Keith

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
Sent: Thursday, July 29, 2010 8:26 PM
To: Laura Liess
Cc: DRAGE, Keith (Keith); [e-mail]; 'Laura Liess'
Subject: Re: [sip-overload] Question on draft-gurbani-soc-overload-control-01


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