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

From: Laura Liess <[email-masked]>
Date: Wed, 28 Jul 2010 17:39:16 +0200

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Jul 2010 11:31:08 +0200

My understanding is that Priority is a header field from one UA to another UA to indicate how the sender intends the recipient to handle the call. I interpret it as the handling in the application above the SIP later in the UA. It has zero impact on intermediate proxy processing, and therefore it should have zero impact on overload control.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Laura Liess
Sent: Wednesday, July 28, 2010 4:39 PM
To: Gurbani, Vijay K (Vijay)
Cc: [email-masked]
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

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 29 Jul 2010 06:31:22 -0400

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 <[email-masked]>
To:
"'Vijay K. Gurbani'" <[email-masked]>
Cc:
[email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Laura Liess <[email-masked]>
Date: Thu, 29 Jul 2010 15:07:08 +0200

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:[email-masked]] 
Gesendet: Donnerstag, 29. Juli 2010 12:31
An: Laura Liess
Cc: [email-masked]; [email-masked]; '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. 

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: 

To: 

Cc: 

[email-masked] 

Date: 

07/29/2010 05:24 AM 

Subject: 

  _____  

Vijay, 

Thanks a lot 

Laura _______________________________________________
sip-overload mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/sip-overload> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Thu, 29 Jul 2010 18:15:07 +0500

I don't understand: if server is already loaded, how it can accept an emergency call (assuming emergency call requires same set of resources) or system always have fixed set of resources for EC reserved. 
What happens if there is an overload for emergency calls?

Regards,
Rahul

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Laura Liess <[email-masked]>
Date: Thursday, July 29, 2010 6:37 pm
Subject: Re: [sip-overload] Question on draft-gurbani-soc-overload-control-01
To: 'Janet P Gunn' <[email-masked]>, 'Laura Liess' <[email-masked]>, [email-masked]
Cc: [email-masked]

> 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
> 
> 
> 
> 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. 
> 
> 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: 
> 
> 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 
> 
> <https://www.ietf.org/mailman/listinfo/sip-overload>

---

From: Laura Liess <[email-masked]>
Date: Thu, 29 Jul 2010 15:45:37 +0200

I think it depends on where the overload is. If your input queue is
overloaded, there is nothing you can do. If your CPU is overloaded you can
drop some part of the messages instead of processing them and lower the
load. The same if the output queue is full. You should not drop ECs.  
I hope I understood your question correctly... 

Thanks 
Laura

> -----Ursprüngliche Nachricht-----
> Von: RahulSrivastava 71616 [mailto:[email-masked]]
> Gesendet: Donnerstag, 29. Juli 2010 15:15
> An: Laura Liess
> Cc: 'Janet P Gunn'; 'Laura Liess'; [email-masked]; sip-
> [email-masked]
> I don't understand: if server is already loaded, how it can accept an
> emergency call (assuming emergency call requires same set of resources)
> or system always have fixed set of resources for EC reserved.
>  This email and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address
> is listed above. Any use of the information contained here in any way
> (including, but not limited to, total or partial disclosure,
> reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this email in error, please
> notify the sender by phone or email immediately and delete it!
> 
> To: 'Janet P Gunn' <[email-masked]>, 'Laura Liess'
> <[email-masked]>, [email-masked]

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 29 Jul 2010 15:26:24 -0400

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

From:
Laura Liess <[email-masked]>
To:
Janet P Gunn/USA/CSC@CSC, "'Laura Liess'" <[email-masked]>, 
<[email-masked]>
Cc:
<[email-masked]>, "'Vijay K. Gurbani'" <[email-masked]>
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:[email-masked]] 
Gesendet: Donnerstag, 29. Juli 2010 12:31
An: Laura Liess
Cc: [email-masked]; [email-masked]; 'Vijay K. 
Gurbani'
Betreff: Re: [sip-overload] Question on 
draft-gurbani-soc-overload-control-01

I would doubt it. 

Janet

From: 

Vijay,

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Jul 2010 08:12:24 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Thursday, July 29, 2010 8:26 PM
To: Laura Liess
Cc: DRAGE, Keith (Keith); [email-masked]; 'Laura Liess'
Subject: Re: [sip-overload] Question on draft-gurbani-soc-overload-control-01

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 the associated SDP (drop messages associated with high bandwidth before you drop messages associated with low bandwidth).

Requirement 13 says

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

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

Janet, Keith,

Thanks a lot
Laura

I would doubt it.

Janet

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

Vijay,

Thanks a lot

---

From: Laura Liess <[email-masked]>
Date: Fri, 30 Jul 2010 09:38:31 +0200

Janet an Keith,

Thank you for clarifying this issue.

Laura

Von: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Gesendet: Freitag, 30. Juli 2010 08:12
An: Janet P Gunn; Laura Liess
Cc: [email-masked]; 'Laura Liess'
Betreff: RE: [sip-overload] Question on draft-gurbani-soc-overload-control-01

regards

Keith

  _____  

Requirement 13 says 

Janet 

From: 

To: 

Janet P Gunn/USA/CSC@CSC, "'Laura Liess'" <[email-masked]>, <[email-masked]> 

Cc: 

Date: 

07/29/2010 09:07 AM 

Subject: 

  _____  

Janet, Keith,

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

I would doubt it. 

Janet

From: 

To: 

Cc: 

[email-masked] 

Date: 

07/29/2010 05:24 AM 

Subject: 

  

  _____  

Vijay, 

Thanks a lot