Subject: RE: [Sipping] Overload solutions comments

From: "Terpstra, Rich" <[email-masked]>
Date: Fri, 28 Jul 2006 08:21:42 -0600

Thanks for the response. These are good points. I wasn't necessarily
suggesting a solution, just pointing out that hop-by-hop helps with some
types of congestion, but doesn't solve all the problems. Perhaps to
solve the problem I put in the example it requires a different method
external to the network itself.

Rich Terpstra
 
Level 3 Communications
Softswitch Architecture
1025 Eldorado Blvd, Broomfield, CO, 80021
 Office: (720) 888-2994

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, July 27, 2006 10:49 PM
To: Terpstra, Rich; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Overload solutions comments

Hi Rich,
Doesn't that imply that UA (B) knows all future pre-paid calling card
calls will go to B2BUA(F), and only (F)?  

My point is proxies can find alternate routes, fork, etc.  If you give
(F)'s congestion back to (B), and he does something with it, you bypass
the intermediate proxies' capability to send the call to B2BUA (F') (a
secondary feature server you don't have on your drawing).  UA(B) will
not know if there is or is not a (F'), because it depends on the owner
of (F) or Proxy(D).  So unless UA(B) knows for all possible AoR's what
all possible final UAS are, it will be gapping when it shouldn't.  

It's just too topology/case specific methinks.

For example what if this was a call center number instead, with hunting.
Or what if the calls were going the other way (to the PSTN) and the PSTN
Gateway was getting congested.

Although I guess if the intermediate Proxies only return the congestion
notification for cases where they have no alternate path for that
AoR/request-uri, it may work, but it means the UA(B) keeps a list of
such congested AoRs.  I think that may get complicated, fast.

I know the pre-paid card number example is real, but to me it's more an
argument/case for code gapping than system overload/congestion control.

My 2 cents.

-hadriel

> -----Original Message-----
> From: Terpstra, Rich [mailto:[email-masked]]
> Sent: Thursday, July 27, 2006 4:07 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] Overload solutions comments
> 
> I don't remember if the working group came to a consensus regarding 
> hop-by-hop versus end-to-end load values for the two different 
> solutions. When reviewing the hop-by-hop approach, I thought of a 
> third possible approach, which is to return the value of the most 
> loaded element to the UAC. This solves a couple of problems that the 
> hop-by-hop doesn't address and keeps the message smaller than the 
> end-to-end approach. It also solves the problem of intermediary 
> proxies not supporting the header, as long as they pass it upstream 
> unchanged. The busiest element approach allows each hop to compare the

> value in the header to its own load value. If the proxy's load is 
> higher, it places itself into the header. Otherwise, it leaves the 
> header as-is and passes it upstream. The UA can decide what to do with

> the information as well as the hop before the congested element.
> 
> The problem I have that the hop-by-hop approach doesn't solve is that 
> as an operator, I see that congestion usually occurs at the UAS and 
> not at the intermediary proxies. A Network normally has multiple 
> routes to reach a UAS through diverse proxies, so the proxies 
> themselves rarely congest. The UAS, however, can become a bottleneck 
> that with the hop-by-hop approach could cause a domino affect to the 
> intermediary proxies. The end-to-end approach allowed the UAC to know 
> that the UAS was congested, so UAC could choose to release some 
> sessions destined for the UAS, which would avoid congesting the 
> intermediary proxies. I believe reporting the most congested element 
> will also allow the UAC to avoid choosing some or all routes based on
which element is congested.
> 
> Consider the following example to illustrate how it appears that 
> hop-by-hop doesn't help alleviate congestion, but in fact acerbates
it:
> 
> 
> 
> +-----+    +-------+    +--------+   +--------+
> | (A) |--->|  (B)  |--->|   (C)  |-->|  (D)   |\
> +-----+    +-------+    +--------+   +--------+ \
>  PSTN          |                                 \+------+
+-----+
>                |                                  |  (F) |----->| (G)
|
>                |                                 /+------+
+-----+
>                |        +--------+   +--------+ /
>                +------->|  (H)   |-->|  (E)   |/
>                         +--------+   +--------+
> 
> 
> SIP 
> ------------------------------------------------------------------>
> 
> (A) - Phone		(E) - Proxy
> (B) - UA		(F) - B2BUA
> (C) - Proxy		(G) - Phone
> (D) - Proxy       (H) - Proxy
> 
> A phone (A) in the PSTN calls a phone (G) on a SIP network. The PSTN 
> routes the call to a carrier who owns the number for phone (G) via a 
> UA (B). The carrier determines that there are two diverse routes 
> through the carrier's network for reaching phone (G). Carrier sends 
> call from UA
> (B) to proxy (C).  Proxy (C) sends call to proxy (D). Proxy (D) sends 
> call to the Feature Server (F) where phone (G) is registered. Call 
> arrives at B2BUA (F), but B2BUA (F) is overloaded. B2BUA (F) will 
> complete the call to phone (G), but will report its load to proxy (D).
> Proxy (D) will pass its load back to proxy (C). Proxy (C) passes its 
> load back to UA (B). Let's say that B2BUA (F) Load = 80, proxy (D) 
> Load = 20, and proxy (C) Load = 30.
> 
> A new call comes into the same UA (B) destined for the same B2BUA (F).
> UA
> (B) sends call to proxy (H). Proxy (H) sends to proxy (E). Proxy (E) 
> does not know about the load on B2BUA (F), so proxy (E) sends call to 
> B2BUA (F). B2BUA (F) completes call to phone (G). B2BUA (F) reports 
> its load now as
> 85 to proxy (E). Proxy (E) reports its load of 20 back to proxy (H).
> Proxy (H) sends back its load of 30 to UA (B).
> 
> A third call comes into UA (B) destined for same B2BUA (F). UA (B) 
> sends call to proxy (C). Proxy (C) sends call to proxy (D). Proxy (D) 
> sees B2BUA
> (F) is loaded at 80, so it chooses not to offer the call to B2BUA (F).
> Proxy (D) releases the call with 503 to proxy (C). Proxy (C) sends 
> back
> 503 to UA (B). UA (B) has a second route to B2BUA (F), so it sends 
> call to proxy (H). Proxy (H) sends call to proxy (E). Proxy (E) sees 
> B2BUA
> (F) is overloaded, so it releases call with 503 to proxy (H). Proxy 
> (H) sends
> 503 back to UA (B). UA (B) fails the call back to the PSTN.
> 
> As you can see from this simple example, if B2BUA (F) load had been 
> relayed back to UA (B), UA (B) could have applied a gapping algorithm 
> to the call to avoid even trying to reach the B2BUA (F). It becomes 
> even more important when there are multiple UA (B) that could send to 
> the B2BUA (F), because then each UA can apply a gapping algorithm 
> independently in order to alleviate the load on the B2BUA (F). Without

> knowing the load of the B2BUA (F), you effectively create a domino 
> affect such that as more calls come in, the network will offer more 
> calls to the downstream proxies fronting the B2BUA (F), which will 
> eventually overload one or both downstream proxies. The proxy (C) will

> then start gapping calls to each proxy (D/E), until the proxy (C) 
> becomes overloaded. At this point, the UA (B) can start call gapping 
> to alleviate the proxy (C). Once proxies
> (C/H) are no longer overloaded, UA (B) will start sending to proxy (C)

> again. The proxies (D/E) may still be overloaded. If so, the proxy (C)

> will eventually go back into an overloaded state.
> 
> As you can see, the hop by hop didn't really help with overload 
> condition. In fact, it compounded the problem by overloading 
> intermediate elements that would not have become overloaded if each 
> element had relayed the B2BUA (F) load to UA (B).
> 
> A real world example of this behavior is for a Customer that offers 
> Pre-Paid Calling Card. Then a holiday like Mother's Day comes around 
> and everyone tries to use the Calling Cards that day. The B2BUA (F) 
> can only sustain 1000 calls simultaneously, but the company has sold a

> million cards. For the 3 minutes a call is up, B2BUA (F), proxies 
> (D/E), proxies (C/H), or UA (B) gap the calls. However, calls continue

> to arrive at many UA's (B) across the country as the 900,000 callers 
> that haven't gotten through continue to hit redial on their PSTN 
> phones. This one event has overloaded the Customer B2BUA (F) and 
> proxies (D/E). This application in addition to other traffic have
overloaded the proxy (C).
> It may even be overloading many UA's (B). However, if all UA's (B) had

> known how busy the B2BUA (F) was, each UA (B) could have 
> alleviated/avoided overloading the UA (B), proxies (C/H), and proxies 
> (D/E). UA (B) could have also freed up the PSTN circuits quicker, 
> which may have resulted in calls to other destinations that would have

> prevented the PSTN from offering as many calls to the overloaded B2BUA

> (F).
> 
> Rich Terpstra
> 
> Level 3 Communications
> Softswitch Architecture
> 1025 Eldorado Blvd, Broomfield, CO, 80021
> Office: (720) 888-2994
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Terpstra, Rich" <[email-masked]>
Date: Fri, 28 Jul 2006 09:40:37 -0600

In general your statement is correct. However, for an IP MS doing IVR
functionality (as in the example below), there are a limited number of
active sessions it can handle due to processing power. The same would
apply to a conference server that may have anything to do with circuits
or bandwidth. I also did not think this ID was restricted to processing
power, but congestion due to any limiting resource. I know the ID
presented by Daryl Malas addressed "any limiting resource". 

Rich Terpstra
 
Level 3 Communications
Softswitch Architecture

-----Original Message-----
From: Janet P Gunn [mailto:[email-masked]] 
Sent: Friday, July 28, 2006 9:15 AM
To: Terpstra, Rich
Cc: [email-masked]; Volker Hilt
Subject: RE: [Sipping] Overload solutions comments

------------------------------------------------------------------------
------------------------------------------------------------------------
--------------------------------

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

I absolutely agree that it is best to stop a  call that can't complete
as early as possible.

However, "not being able to complete" is far more likely to be because
of a shortage of transmission resources (e.g., bandwidth, circuits at
the
gateway) than a shortage of processing resources at the SIP device.

This group of IDs are focused JUST on (processing related) congestion in
the SIP device.  NOT congestion related to bandwidth.circuits, or
congestion at the end device.

That is why I found this comment a bit odd:

"The B2BUA (F)  can only sustain 1000 calls simultaneously, but the
company has sold a million cards."

The call only imposes processing load on the B2BUA when setting up or
tearing down the call. It doesn't impose processing load just to
"sustain"
the call, so the number of simultaneous calls isn't likely to be an
important factor in triggering these overload messages.

If there is a limit on the number of simultaneously ACTIVE calls,
whether because of bandwidth restrictions, or logical restrictions in
the SIP device, I think that a 488 (Not Acceptable Here) response  (with
the appropriate warning code) is what would be needed in your example.

Janet

"Terpstra, Rich" <[email-masked]> wrote on 07/28/2006 10:48:42
AM:

> Thanks. I was really just pointing out a real problem to consider to 
> see if whatever approach is selected will help solve it. As a network 
> operator, if I can stop a call that can't complete as early in the 
> process as possible, it saves my resources for other calls that I can 
> complete. I am hoping that the overload header will help with this 
> problem.
>
>
> Rich Terpstra
>
> Level 3 Communications
> Softswitch Architecture