Subject: [stir] 15ms??? Where the heck did that come from?

From: Eric Burger <[email-masked]>
Date: Mon, 5 Aug 2013 16:37:00 -0400

In the STIR BOF I mentioned that the time budget for *additional* processing in the PSTN world would be on the order of 15ms. I need to put a LOT of context around that statement.

Twenty years ago (NOT TODAY), routing special PSTN calls, like free phone or virtual networks, had a very tight time budget. There were both government performance mandates and consumer drivers that ensured carriers routed calls quickly. The big driver is callers might wait up to 2500ms before they would abandon the call. At my company, the saying we had was we never want one of our customers to say, "Why did I ever switch from brand A?" as they hung up the phone and redialed.

Given the latencies of local switches routing to long distance switches, the latencies of breaking out call signaling to make a dozen or so data base lookups, and returning the result so the call could be routed to its destination, our total processing budget was 70ms. That was the days of 30ms access time disks, so you can see the problem.

So, on the one hand, in an IP environment we have a lot more time than 15ms to do authentication steps, as we can do that work in parallel to other routing logic. We are not restricted to adding on the exchanges and algorithms in sequence to other routing processing.

On the other hand, the statement that the budget is 10000ms is beyond reality. Even in a World of Warcraft chat room, no one is going to wait 10 seconds in the hope a connection request is successful. Granted, mobile phones and early VoIP systems have trained users to have a little more patience than 2500ms. However, to expect a user, in a PSTN emulation environment, to hang on for more than 4000ms or 5000ms is wishful thinking.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Aug 2013 07:38:00 -0400

Agreed - the budget is not as low as 15ms, but nowhere near as high as 4 seconds.  It's actually quite hard to come up with a hard limit though, as a general requirement for STIR for all scenarios.  Generally I just think of it as: "as low as we can possibly make it".

Some people have been talking about it from the perspective of acceptable post-dial-delay (PDD), but I think that's the wrong way to think about it - because STIR is adding additional time to whatever is already deployed today.  So the real question is how much *additional* time do we think STIR can introduce, without being a barrier to adoption.  That's why for me the topic boils down to "make it super-frigging' fast".

As an equipment vendor, for example, my employer gets requirements for SIP message processing in the order of single-digit milliseconds if there's no external DB query.  Even when we query external databases, we're sometimes required to stop waiting for a DB answer after only tens of milliseconds (or less than 100ms), and forward the call on regardless.  This may be because some wholesale carrier SLAs are measured on post-dial-delay; or it may just be because so many systems are involved in call processing, and the cumulative delay would become so untenable, that the carriers decide to require a consistent common max value for all systems.  I don't know for sure.  Either way, carriers are very sensitive to call delays.

[As an aside for those who care: according to ITU E.721, the mean delay budget for end-to-end PDD is 3 seconds for local calls, 5 seconds for national long-distance, and 8 seconds for international.  But that spec is really conservative and is based on phone-to-phone time.  For the SS7 network, a different spec (E.723) gives the end-to-end PDD across the SS7 system as 0.9 seconds for local calls, 2.3 seconds for long-distance, and 4 seconds for international.  Mobile phones/networks have a different set of values, I believe.  But again, looking at these numbers provides a false sense of time budget for STIR.]

-hadriel

On Aug 5, 2013, at 4:37 PM, Eric Burger <[email-masked]> wrote:

> On the other hand, the statement that the budget is 10000ms is beyond reality. Even in a World of Warcraft chat room, no one is going to wait 10 seconds in the hope a connection request is successful. Granted, mobile phones and early VoIP systems have trained users to have a little more patience than 2500ms. However, to expect a user, in a PSTN emulation environment, to hang on for more than 4000ms or 5000ms is wishful thinking._______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Michael Hammer <[email-masked]>
Date: Tue, 6 Aug 2013 13:26:55 +0000

I don't think those are false numbers, those are what people are used to.
Technology moved forward, we don't want to start doing worse and worse.
We also need to avoid having any cumulative delay across multiple networks.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Tuesday, August 06, 2013 7:38 AM
To: Eric Burger
Cc: IETF Mail List STIR
Subject: Re: [stir] 15ms??? Where the heck did that come from?

Agreed - the budget is not as low as 15ms, but nowhere near as high as 4
seconds.  It's actually quite hard to come up with a hard limit though, as a
general requirement for STIR for all scenarios.  Generally I just think of
it as: "as low as we can possibly make it".

Some people have been talking about it from the perspective of acceptable
post-dial-delay (PDD), but I think that's the wrong way to think about it -
because STIR is adding additional time to whatever is already deployed
today.  So the real question is how much *additional* time do we think STIR
can introduce, without being a barrier to adoption.  That's why for me the
topic boils down to "make it super-frigging' fast".

As an equipment vendor, for example, my employer gets requirements for SIP
message processing in the order of single-digit milliseconds if there's no
external DB query.  Even when we query external databases, we're sometimes
required to stop waiting for a DB answer after only tens of milliseconds (or
less than 100ms), and forward the call on regardless.  This may be because
some wholesale carrier SLAs are measured on post-dial-delay; or it may just
be because so many systems are involved in call processing, and the
cumulative delay would become so untenable, that the carriers decide to
require a consistent common max value for all systems.  I don't know for
sure.  Either way, carriers are very sensitive to call delays.

[As an aside for those who care: according to ITU E.721, the mean delay
budget for end-to-end PDD is 3 seconds for local calls, 5 seconds for
national long-distance, and 8 seconds for international.  But that spec is
really conservative and is based on phone-to-phone time.  For the SS7
network, a different spec (E.723) gives the end-to-end PDD across the SS7
system as 0.9 seconds for local calls, 2.3 seconds for long-distance, and 4
seconds for international.  Mobile phones/networks have a different set of
values, I believe.  But again, looking at these numbers provides a false
sense of time budget for STIR.]

-hadriel

On Aug 5, 2013, at 4:37 PM, Eric Burger <[email-masked]> wrote:

> In the STIR BOF I mentioned that the time budget for *additional*
processing in the PSTN world would be on the order of 15ms. I need to put a
LOT of context around that statement.
> 
> Twenty years ago (NOT TODAY), routing special PSTN calls, like free phone
or virtual networks, had a very tight time budget. There were both
government performance mandates and consumer drivers that ensured carriers
routed calls quickly. The big driver is callers might wait up to 2500ms
before they would abandon the call. At my company, the saying we had was we
never want one of our customers to say, "Why did I ever switch from brand
A?" as they hung up the phone and redialed.
> 
> Given the latencies of local switches routing to long distance switches,
the latencies of breaking out call signaling to make a dozen or so data base
lookups, and returning the result so the call could be routed to its
destination, our total processing budget was 70ms. That was the days of 30ms
access time disks, so you can see the problem.
> 
> So, on the one hand, in an IP environment we have a lot more time than
15ms to do authentication steps, as we can do that work in parallel to other
routing logic. We are not restricted to adding on the exchanges and
algorithms in sequence to other routing processing.
> 
> On the other hand, the statement that the budget is 10000ms is beyond
reality. Even in a World of Warcraft chat room, no one is going to wait 10
seconds in the hope a connection request is successful. Granted, mobile
phones and early VoIP systems have trained users to have a little more
patience than 2500ms. However, to expect a user, in a PSTN emulation
environment, to hang on for more than 4000ms or 5000ms is wishful
thinking._______________________________________________
> https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Aug 2013 15:57:00 +0200

The ideal is that this be done in *parallel*, not *series* with other 
processing, so that most of the cost doesn't normally add to the delay.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 Aug 2013 19:54:29 -0400

And out of band can be parallel. However, here's an interesting thought: the client is most likely going to 183 the call until it gets the authenticated response. That means service providers are going to be holding the bag for Xms extra for, if STIR is successful, every call. That's hundreds of millions of minutes per month. Good thing we are not talking TDM where DS0's would be allocated and blocked!

On Aug 6, 2013, at 9:57 AM, Paul Kyzivat <[email-masked]> wrote:

> The ideal is that this be done in *parallel*, not *series* with other processing, so that most of the cost doesn't normally add to the delay.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Aug 2013 19:36:31 +0200

> And out of band can be parallel. However, here's an interesting thought: the client is most likely going to 183 the call until it gets the authenticated response. That means service providers are g…

And do you expect the cost of those extra ms of just waiting to be 
significant?

How does that trade off against reducing the processing of unwanted calls?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 14:11:08 -0400

Sure, that's the ideal.  In practice, it won't and can't be ideal.  For example, even if the system you decide to do verification in already delays calls for 100ms for other database lookup reasons, if the STIR database lookup takes 500ms then the extra 400ms of time is 400ms of additional PDD delay time.  And that's assuming you're doing it on a system that has such delay already today.

But none of that was my point.  My point was some people have been talking about STIR overhead as being unimportant because users expect a X number of seconds of PDD so we have a X seconds to play with, and I was just saying "no, you don't have X".

-hadriel