Subject: [sip-overload] Alignment of priority and emergency call handling

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Jul 2012 03:01:11 +0200

5.10.1 of draft-ietf-soc-overload-control-09 contains the text:

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

   Local policy could also include giving precedence to mid-dialog SIP
   requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload.  A
   local policy can be expected to combine both the SIP request type and
   the prioritization markings, and SHOULD be honored when overload
   conditions prevail.

While draft-ietf-soc-load-control-event-package-03 covers priority, it does not say anything specifically about emergency calls, see as follows:

   In addition, whatever the actual policy is, SIP
   servers SHOULD honor the Resource-Priority Header (RPH) [RFC4412]
   when processing messages.  The RPH contents may indicate high
   priority requests that should be preserved as much as possible, or
   low priority requests that could be dropped during overload.  SIP
   request rejection and message prioritization at an overloaded server
   are also discussed in Section 5.1 of [I-D.ietf-soc-overload-control]

It would therefore appear sensible that the two drafts are aligned.

Regards

Keith

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 26 Jul 2012 07:48:35 -0500

Keith: Please see inline.

On 07/25/2012 08:01 PM, DRAGE, Keith (Keith) wrote:
> While draft-ietf-soc-load-control-event-package-03 covers priority,
> itdoes not say anything specifically about emergency calls, see as follows:
>

draft-ietf-soc-overload-control-09 states that, "... Other indicators,
such as the SOS URN [RFC5031] indicating an emergency request, may also
be used for prioritization."

Do we need to include other artifacts besides the SOS URN and RPH for
emergency call handling?  If so, can you please specify which ones?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Jul 2012 17:23:21 +0200

I do not believe you need to include other artifacts.

Rather overload-control lists both RPH and sos URN, and the event package lists only RPH.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Vijay K. Gurbani
> Sent: 26 July 2012 13:49
> To: [email-masked]
> Subject: Re: [sip-overload] Alignment of priority and emergency call
> handling
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 26 Jul 2012 11:03:44 -0500

> Rather overload-control lists both RPH and sos URN, and the event

So it is a simple matter of ensuring that the text in
draft-ietf-soc-load-control-event-package is consistent with the
text in draft-ietf-soc-overload-control?

If so, Charles --- can you please take care of this in
draft-ietf-soc-load-control-event-package?

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Sun, 29 Jul 2012 17:49:01 -0400

I agree with Keith's comments about priority and emergency calls.

I also have a number of other comments, mostly editorial (I apologize for my lateness in responding).

Introduction should stress that this approach is for situations where you can predict, in advance, a likely traffic surge,

and its source/destination distribution.  For instance, it is appropriate for a mass-phone-voting event, Mother's Day, New

Years, and even a hurricane (there is usually some advance notice).

However, it is less likely to be effective for the initial phase of unpredicted/unpredictable mass calling events, such as

earthquakes or terrorist attacks.  In these latter cases, the local traffic load may peak by more than an order of magnitude

in minutes, if not seconds.  This does not allow time to either
effectively identify the filters needed, nor distribute then to the appropriate servers, soon enough to prevent congestion

attack.  Once other, more immediate, techniques (such as the loss-based or rate-based  methods) have prevented the initial

congestion collapse, the event package can be used to effectively control the continuing overload.

--

This sentence
Load filtering works best if it prevents calls as close to
the user agent clients as possible.

could be clarified by including the word "originating"
Load filtering works best if it prevents calls as close to
the originating user agent clients as possible.

--

There appears to be a cut and past error here

Secondly, since we are describing a specific control
mechanism based on filtering, the term "load control" in this
specification is used inter-changeably with the term "load filtering"
unless when associated with other explicit context.

I suspect it is supposed to be

Secondly, since we are describing a specific control
mechanism based on filtering, the term "load control" in this
specification is used inter-changeably with the term "load filtering"
unless associated with other explicit context.
--

I am not sure I understand this statement

This
specification, however, does not preclude the load control document
defined here (Section 6) to be extended in the future for other forms
of control as appropriate.

What sorts of "other forms of control" are you referring to?  Presumably not service level and QoS control, as you have

already defined them (or at least referred to them) as "load control" but not "overload control".
--

Section 3

I think that

For destination-specific overload situations, the load filter
needs to be able to describe the callee.

should be

For destination-specific overload situations, the load filter
should be able to specify the callee.

--

This bullet

To address accidental and intentional high-volume call generators,
the load filter should allow to specify the caller.

does not use correct grammar.

I suspect you mean

To address accidental and intentional high-volume call generators,
the load filter should be able to  specify the caller.

--
With regard to this bullet,

o  For telephone numbers, it should be possible to specify prefixes
which allow control over limited regionally-focused overloads.

This is really an assumption rather than a requirement.

Furthermore, I do not believe it is true.  In these days of number portability, and people retaining their original mobile

phone number, as their primary number, when they move across the country, the correlation between "telephone number prefix"

(aka area code) and "physical location" is rapidly decreasing.

I agree that,for regional calling events, you need a way of identifying the geographical location (originating and/or

terminating) to determine which calls to filter.  But I do not think that area codes will continue to be the most effective

way of doing this.

Perhaps an alternate wording would be

o  It should be possible to specify particular information in the SIP headers (e.g., prefixes in telephone numbers)
which allow control over limited regionally-focused overloads
---

sec 4.2
in this statement

and that loads are allocated in a way which
both prevents overload and minimizes the likelihood of network
resource under-utilization.

would it be better to say "maximizes effective throughput(aka goodput)" instead of "minimizes the likelihood of network
resource under-utilization."?

---

sec 4.3

Should this

In order for load filters to be properly distributed, each SIP proxy
server in the network is required to subscribe to the load control
event package from all its outgoing signaling neighbors, known as
notifiers (Section 5.6).

be

In order for load filters to be properly distributed, each SIP proxy
server in the network SHOULD subscribe to the load control
event package from all its outgoing signaling neighbors, known as
notifiers (Section 5.6).
? (not sure myself)

---

For case II, perhaps "hurricane" (which has a more predictable, and more gradual, increase in traffic) would be a better

example than "earthquake", due to the issues mentioned above.
--

Sec 5.3

In sec 4.4 you say

Another important aspect that affects the applicability of SIP load
filtering is that all possible signaling source neighbors need to
participate and enforce the designated filter.  Otherwise, a single
non-conforming neighbor could make the whole control efforts useless
by pumping in excessive traffic to overload the server.

But in section 5.3 you say

a subscriber may be interested in some
specific types of load control policy only.

Maybe I am misunderstanding what you mean by "types of load control policy", but the statement in 5.3 ("only interested in

some") seem inconsistent with the statement in 4.3 ("all must participate").  Perhaps you could add a clarifying statement.

---

5.8

Modifications of existing load
control policies at the subscriber is performed after directly
receiving notifications containing updated load control policies.

Grammar
either
... modifications ... are ...
or
...modification ...is ...

but NOT
... modifications ... is ...

---
5.11

This sentence
"Another factor usually not known precisely or is
computed automatically is the validity duration of the load control
event."
Seems to be a cut and paste error of some sort.

...

8.1
Should this
"... administrative option for routing failed
call attempts to either Recorder Tone or a special announcement...."
be "Reorder Tone" instead of "Recorder Tone"?

Janet

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

To: [email-masked]
From: "Vijay K. Gurbani"
Sent by: [email-masked]
Date: 07/26/2012 12:03PM
Cc: [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

Thanks,

- vijay

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: Charles Shen <[email-masked]>
Date: Sun, 29 Jul 2012 23:08:49 -0400

Hi Vijay,

I will do. Thanks

Charles

---

From: Charles Shen <[email-masked]>
Date: Sun, 29 Jul 2012 23:35:22 -0400

Hi Janet, thank you very much for your detailed comments! I've
incorporated them in the new revision. Also please see response
inline.

> I agree with Keith's comments about priority and emergency calls.

done

> Introduction should stress that this approach is for situations where you
> can predict, in advance, a likely traffic surge,
> and its source/destination distribution.  For instance, it is appropriate
> for a mass-phone-voting event, Mother's Day, New
> However, it is less likely to be effective for the initial phase of
> unpredicted/unpredictable mass calling events, such as
> earthquakes or terrorist attacks.  In these latter cases, the local traffic
> load may peak by more than an order of magnitude
> effectively identify the filters needed, nor distribute then to the
> appropriate servers, soon enough to prevent congestion
> attack.  Once other, more immediate, techniques (such as the loss-based or
> rate-based  methods) have prevented the initial

agree.

>  the originating user agent clients as possible.

right

>    unless associated with other explicit context.

right

> What sorts of "other forms of control" are you referring to?  Presumably not
> service level and QoS control, as you have

Yes, it could be confusing, so I removed this sentence.

>       should be able to specify the callee.

agree.

>       the load filter should be able to  specify the caller.

agree

> Furthermore, I do not believe it is true.  In these days of number
> portability, and people retaining their original mobile
> phone number, as their primary number, when they move across the country,
> the correlation between "telephone number prefix"
> I agree that,for regional calling events, you need a way of identifying the
> geographical location (originating and/or
> terminating) to determine which calls to filter.  But I do not think that
> area codes will continue to be the most effective
> way of doing this.
>    o  It should be possible to specify particular information in the SIP
> headers (e.g., prefixes in telephone numbers)

agree

> would it be better to say "maximizes effective throughput(aka goodput)"
> instead of "minimizes the likelihood of network

agree

>    event package from all its outgoing signaling neighbors, known as

agree.

> For case II, perhaps "hurricane" (which has a more predictable, and more
> gradual, increase in traffic) would be a better
> Maybe I am misunderstanding what you mean by "types of load control policy",
> but the statement in 5.3 ("only interested in
> some") seem inconsistent with the statement in 4.3 ("all must participate").
> Perhaps you could add a clarifying statement.
> ---

Since the details of the subscription filter specification are not
defined anyway, I removed this "For example" sentence to avoid the
confusion.

> ... modifications ... is ...

right

> Seems to be a cut and paste error of some sort.

Changed to "  Another factor that is usually not known precisely or
needs to be computed automatically is the validity duration of the
load control event.  "

> be "Reorder Tone" instead of "Recorder Tone"?

I think this is something like a recording machine playing something
message, am I correct?

thanks

Charles

> 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: Janet P Gunn <[email-masked]>
Date: Mon, 30 Jul 2012 18:03:27 -0400

Thanks

WRT the last comment - "Reorder tone" is also known (at least in the US) as "fast busy".

I agree that there might be "announcements"

but I do not know what you mean by "Recorder tone". Do you mean the tone that sometimes comes on just BEFORE an announcement?

Janet

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

To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: [email-masked]
Date: 07/29/2012 11:35PM
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

done

agree.

right

right

agree.

agree

agree

agree

agree.

right

thanks

Charles

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 31 Jul 2012 00:18:49 +0200

Can I suggest that we stick to the terminology available in ITU-T Recommendation E.182 (and E.180) as this U.S. terminology is very specific to the U.S. and other terms are used elsewhere in world.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: 30 July 2012 23:03
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

Thanks

Janet

[email-masked] wrote: -----
To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: [email-masked]
Date: 07/29/2012 11:35PM
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

done

agree.

right

right

agree.

agree

agree

agree

agree.

right

thanks

Charles