Re: Overload Controls for IUA

Dear Brian/SIGTRAN,

Apologies for the delay is response. In this email I will attempt to
answer questions and concerns highlighted in your email. If however for
some reason you feel I have wrongly interpreted them, please do say so
and I will re-attempt to answer them. So;

"For ISDN, in the case of en-bloc dialing, it is the Digital handset/TA
that provides dial tone and collects digits, not the IUA SG.  The SG
neither generates nor terminates Q.931 messages.  It backhauls the Q.921
data link to the MGC.  Therefore, without a significant architectural
change, the SG cannot prioritize call attempts."

I totally agree that we need a significant architectural change, and
this is why we are proposing this complete new layer of overload
controls, within the IUA. This will help us to deal with the problem on
the first stage of call setup rather than shifting the problem onto the
next stage (AGC) to deal with it. Another important bits to remember
here is that although the AGC can be designed to deal with two or three
times the optimum load, it cannot however be designed to deal with 10 to
12 times the traffic load that can occur once for 15 to 20 minutes per
month or an hour per year. Hence we cannot expect nationwide traffic to
overload the CS and hope the CS to cope with all call attempts. Just to
add, there is however a significant number of SGs that provide the dial
tone before collecting the digits.

Secondly, we cannot expect the CPs interconnecting into BT's Network to
be fair with the traffic they send over the interconnect. This will add
to the traffic generated within BT's Network, hence a protective
mechanism within the protocol itself will help avoid potential times of
distress for the network.

"... the MGC is fully capable of throttling messages sent by an SG by,
for example, closing the SCTP receive window, or simply by having the
ULP no longer retrieve messages from SCTP..."

As mentioned in the email about "... Closing the SCTP receive window
...", I would say that closing the SCTP window would mean that no new
SETUP messages are being sent through, hence it makes it impossible to
identify an emergency call (999, 112, 911, etc) at Layer 2 and hence a
layer 3 (application layer) is being proposed here to overcome this
limitation and allow an emergency call to pass through during times of
network overload. This goes hand in hand with the fact that you have
highlighted in your email that there is no L3 proxy in the SGW and we
accept that fact. We are infact proposing the introduction of this L3
functionality. This Layer 3 can be either a simple solution or a highly
complex solution, and at its simplest it could be a "call identifier",
which will knock out a SETUP (outgoing calls) and all subsequent related
messages on that Call Reference. 

It can even be a more complex solution and do digit collection &
analysis to overlap (but not necessary).

Whatever this Layer 3 function is, it has to be given rejection rate
info by the AGC. This is the IUA enhancement required and our proposal
is to have this as an optional enhancement, design to effectively manage
focused overload at the CS rather than just cope with the overload.

So, please note that we are not suggesting a solution here. We are
attempting to highlight a weakness and proposing to have the option
within the standards to implement "a" solution (of CP's choice) to get
over the risk of hitting overload and network failure.

As far as the "correctness of the ES 293 039-4" is concerned I will let
the author of that piece of work suggest how it is infact correct and
sits in well with the proposal and the motivation for which the way this
control is designed.

Hope this helps.

Kind Regards,

Hassan Malik

*************************
Hassan M Malik.
E2 103A
BT Brentwood WS2000
One London Road 
Brentwood 
Essex CM14 4QP 
Mobile: + 44 7931 787650
*************************

British Telecommunications plc 
Registered office: 81 Newgate Street London EC1A 7AJ 
Registered in England no. 1800000 
This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately. 
Activity and use of the British Telecommunications plc E-mail system is
monitored to secure its effective operation and for other lawful
business purposes. Communications using this system will also be
monitored and may be recorded to secure effective operation and for
other lawful business purposes.


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: 30 July 2008 07:34
To: Malik,HM,Hassan,DMM R
Cc: [email protected]
Subject: Re: [Sigtran] Overload Controls for IUA

hassan.malik,

First, let me apologize for the length of this note.  Those without an
interest in the area of mass calling events or collective behaviours
just skip this note.  Hassan, please see comments below:

>    The analogue call attempts may be effectively controlled using
>    etsi_nr, however a similar mechanism is not available for ISDN call
>    attempts. And therefore a new mechanism to enable the MGC to
regulate
>    the number of IUA (QPTM) messages is necessary in order to prevent
>    congestion collapse of the MGC.
> 
>    For your information, etsi_nr is a rate based overload control
>    mechanism for H.248  which is described in ETSI ES 283 039-4 and is
>    freely available from ETSI website.
> 
>    I would like to know that if there is any interest in this proposal
to
>    produce an draft RFC to cover this rate based overload mechanism
for
>    IUA, work has just started within ETSI and we would like to have a
>    single mechanism in this area as it does not make sense for
multiple
>    solutions in this space so we would propose to maintain alignment
of
>    the work in the two standards bodies.

Were you intending on writing the draft?

There are problems with trying to take a similar approach the IUA.  In
the AGW case, the AGW autonomously responds to off-hook with dial tone
and prioritizes calls (optionally) using defined digit string prefixes.
Then, based on priority, the AGW throttles off-hook indications to the
MGC based on previous instructions from the MGC.  Note that H.248 using
UDP as a transport has no flow controls.

For ISDN, in the case of en-bloc dialing, it is the Digital handset/TA
that provides dial tone and collects digits, not the IUA SG.  The SG
neither generates nor terminates Q.931 messages.  It backhauls the Q.921
data link to the MGC.  Therefore, without a significant architectural
change, the SG cannot prioritize call attempts.  On the other hand, IUA
uses SCTP for transport.  SCTP has built in flow control.  That is, the
MGC is fully capable of throttling messages sent by an SG by, for
example, closing the SCTP receive window, or simply by having the ULP no
longer retrieve messages from SCTP.

Furthermore, unlike the POTS AGW case, where the MGC would normally have
to respond to an off-hook to obtain digits to determine priority,
initial Q.931 call attempt message (SETUP) contains all of the
information necessary for prioritization (en-bloc) and some or all of
the information necessary for prioritization (overlap).  If the MGC does
not want to commit resources to the call attempt (because it is
overloaded), it can simply discard the (SETUP) message, causing the
orignator to eventually time-out.  This can also be on the basis of the
MGC's knowledge of the availability of other resources (e.g. outgoing
911 trunk occupancy) which is far more sophisticated than ETSI ES 293
039-4.

<rant comment="everyone might want to skip this following part">

Which brings up another point.  I don't think that ETSI ES 293 039-4 is
quite correct.  Its approach is too simplistic and does not follow an
understanding of (what I have termed in the past to be) a Significant
Calling Event.  The most appreciable significant calling event for most
is the catastrophic event.  I had the experience of analysing the
effects of calling patterns placed on local telephone exchanges during
an completely unexpected F4 tornado that touched down in Edmonton,
Alberta, Canada on July 31, 1987 (or Black Friday as it was called):

 http://archives.cbc.ca/environment/extreme_weather/topics/1713-11760/

also

 http://en.wikipedia.org/wiki/Edmonton_tornado

What the article wont tell you is the effect on the telephone system.
One local switching exchange was ripped from the ground, severing trunks
to neighboring switching, casing bogus trunk seizures and endagering
neighboring switches, but that was minor.

The Significant Calling Event that occurred was that everyone (and I
mean 60-80% of the residential lines) persistently went off-hook trying
to contact (wait for it...) 911.  Now there were two types of switching
exchange, those that were BHCA limited and those that were occupancy
limited.  Both types of switches when presented with too many off-hooks
on analog POTS lines, simply delay dial tone.  The BHCA one do that to
protect them from going down hard, but the BHCA ones always throttled
too heavily and the resuling call handling only represented a portion of
the calling handling capacity of the switching exchange, resulting in
even more off-hook refusals.  The call occupancy limited switches were
engineered to provide priority allocation across the switching matrix to
specially marked 911 trunks.  Unfortunately, a significant amount of SPC
resources needed to be allocated before it could even be discovered that
the 911 trunks were all-trunks-busy.

The result on both switch types was that it was nearly impossible to
make a call to a number other than 911.  Unfortunately it is the general
public that calls 911 and not the emergency personnel that normally
respond to those calls and need to communicate between them.  The city's
ability to respond to the disaster was severely hampered by the
inability of those with the disaster plans to communicate with those
that needed to implement them quickly.

Now, I bring this up because the ETSI ES 283 039-4 document describes
using prefix for prioritization (presumably 911) which in the analysis
of these events is the wrong thing to do.  What is needed in such
situations is more of a TDR/ETS approach where the lines associated with
emergency response are given priority over 911 calls.

Now, the other application that ETSI ES 283 039-4 mentions is
tele-voting.  It just so happens I worked on those too.  The other
"Significant Calling Event" is what is termed mass calling.  The typical
scenario of yesteryear was the radio call in promotion that goes
something like this: a radio station advertized that tickets to the
Rolling Stones concert that sold out 10 show times (or free beer or
whatever) will be given away to the third caller and broadcast the
call-in number.  Suddenly all their listeners leap to the phone and
start dialing the radio station.  When they get busy, the hang up, go
off hook, and hit redial.  After a while they give up, or they get
through to the recorded announcement that tells them that the tickets
(or beer) is already gone.  Now this is nowhere near staring an F4
tornado in the face (then the caller simply will not give up).  In fact,
these mass calling events don't even blip on the BHCA for originating
call attempts on local switch access because they are widely distributed
across the network.  Where they do cause problems is that they tie up
the local trunks between switches necessary to get to the switch that
hosts the radio talk show number, and also because they focus more call
attempts on the terminating switch than can be handled by the PBX trunks
to the radio station. (I call this the "focus" switch).  This has an
negative impact on the trunks because when the call attempt is refused
by the terminating switch there is a guard time for which the circuit is
unavailable.  In analyzing the effects of SS7 on the situation, it is
easy to understand that SS7 signalling worsens the situation (largely
because it has less of a guard time, permitting a higher rate of call
attempts to the "focus" switch).

Now the typical way to handle this is a choke group.  A choke group is a
dedicated trunk group established between the "focus" switch and each
switch in the mass calling area (e.g. broadcast area of the radio
station).  These used to be physical trunk groups at one time, but they
were move to "virtual" trunk groups within the existing interswitch
trunk groups at a latter date.  These choke groups (be they physical or
virtual) were provisioned with members in proportion to the number of
access lines on the originating switch and also sized to be less than or
equal to the the number of terminating PBX trunks at the radio station.
Radio stations and other entities with broadcast coverage (e.g. TV
stations) were required by law to notify the telephone company so that
these choke groups could be established before the promotion.  I did an
analysis on using AIN code-gapping as a possible replacement for choke
groups and discovered in the analysis that AIN code-gapping would
increase the call attempt rates (because it gives all-trunks-busy or
busy signal more rapidly allowing the originator to simply reattempt
faster).  It also would increase the SS7 signalling load
(quasi-associated) significantly beyond that of the trunk guard time
limited ISUP signalling.

I experienced one interesting event where the PBS (public broadcasting)
television station in Spokane was running a sponsorship telethon, and,
of course had registered with the telephone company for choke groups,
but nobody in the phone company realized that their primary subscriber
base was in Calagary just north of the Canadian border.  And, of course,
PBS knowing this, advertized an 800 (toll free) call-in number that was
accessible from Canada.  With no choke group between Calgary and Spokane
in the long distance telephone network, 800 database queries swamped the
800 SCPs that focussed all of the traffic and took out the toll free
long distance network.  ETSI ES 293 039-4 would not have helped here
either.

So, the point is that AWG access throttling does not work for mass
calling events such as tele-voting, because the originating MGC is never
overloaded: it is the terminating MGC that can overload as well as the
network being swamped to the "focus" MGC that is the problem.

So, I would put it to you that the ETSI ES 293 039-4 is wrong for both
Significant Calling Events: catastrophic and tele-voting.

Now, even worse, the MGC loading model in the document is poor (even
wrong) because it takes a nodal view of overload instead of a network
view.  A nodal model for both catastrophes and mass calling is
inappropriate.  The interaction with network resources (e.g. choke
groups dedicated 911 groups) is significant.  The NGN network should
likely be using the TRD/ETS approaches similar to that discussed for
Emergency-RSVP.  Any nodal overload model does not address the
significance of the interaction between the MGC and network mechanism
such as Emergency-RSVP.

You can find some more information (and read me reciting this old story
that dates me as an old fart again) on the tsvwg thread entitled
"<draft-lefaucheur-emergency-rsvp> : Preemption scope" from June 5 of
2006.

Which brings up even another point: that ETSI ES 293 039-4 does not
address preemption.

</rant>

--brian

--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran