Re: Overload Controls for IUA

Brian,

Once again thanks for the response.

All,

The purpose of this email was to gauge interest from IETF. Considering
BT is serving over 20 Million customers this recommended piece of work
is essential to the network's operational requirements. As mentioned
before this work is being pursued in the ETSI, and we will very much
appreciate IETF's contribution to overcome the highlighted issues,
irrespective of the reasons for the trigger (media or emergency).

For everyone's benefit, yes I am intending to produce a draft, hence the
email to check for other interested parties who would like to provide
any input. We strongly believe that there is atleast a need of having
the option to 'manage' the problem before it happens, rather than having
to cope with it 'if and when' it happens and having a potentially
detrimental effect.

A detailed response to Brian's descriptive email will follow soon.

Kind Regards,

Hassan 


*************************
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 

-----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/