Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

From: [email-masked]
Date: Tue, 3 Dec 2002 10:28:29 EST

In a message dated 12/2/2002 4:38:56 PM Eastern Standard Time, 
[email-masked] writes:

> On Monday, Dec 2, 2002, at 10:30 America/Montreal, [email-masked] 
> wrote: 
> > [MAP] So take this simple case and apply an emergency. (I'd like to 
> > see the performance last week right after the bombing in Kenya!) 
> > 
> > If 10 or 20 or whatever number of those "several thousands" of end 
> > users tried to make a VoIP call via that single 384K link, what would 
> > have happened? It is my understanding that, at some point, the 
> > overload would have caused either: 
> > 
> > 1. all calls to be of unacceptable quality 
> > 2. new call attempts would have been rejected 
> 
> [MAP] I'll repeat the question which I don't believe I've gotten any
> concrete answer to: In the case above of the 10 callers from Nairobi, if
> one of them was authorized to make emergency calls and the other 9
> weren't, what specific standardized mechanism (not products) could be
> used to provide the required service across the congested 384 kbit/s
> satellite link? (The required service is that their call gets set up and
> they can talk.) If you don't believe that 10 users would cause
> congestion, then make it 20 or however many of the several thousand it
> would take. 
> 
> Mike,
> 
> The answers to your question depends upon the assumptions you make (i.e.,
> problem context).  Do you assume your 10 or however many users are just
> random folks who happen to be using the same access link owned by an
> arbitrary ISP?  Then your answer is very likely to be "the call quality for
> all users is going to be poor".  

[MAP] The case began with that situation, and, as you said, all users get 
poor quality (probably too poor to converse at some point of congestion). The 
case then moved on to the one of 9 random folks and 1 with authorized 
emergency access.

> 
> Let's us examine why...well, we could try to identify emergency users with
> SIP signaling and try to use "call admission control" in the telco sense.
> Fine except your 10 users might use 10 different SIP service providers
> completely unconnected to the ISP who happens to be providing the access
> link.  Those SIP providers certainly have no way of knowing what other SIP
> service providers are doing nor do they track bandwidth utilization across
> some random link (they have no way to do this) hence they can't provide a
> "call admission control".  So, you can then assume all 10 users are allowed
> to setup calls.  Your access link provider is quite likely to be just moving
> 

[MAP] Yes, I understand that 10 independent SIP providers can't know about 
the link loading in order to decide whether or not to allow a new call to be 
set up (which is going to "fail" anyway due to bad audio). This is a major 
shortcoming with SIP and VoIP and IP routing and until it is recognized, 
admitted, and fixed, it can not be used for real telephone service (much less 
emergency services).
> 
> So, with these set of assumptions, the answer is the call quality will be
> 

[MAP] And, as we know from the telephony world, many of those who hang up 
will immediately redial.

> 
> But, under a different set of assumptions, the answer is different.  Assume
> all 10 users have a local soft PBX that provides a "call admission control"
> for all off net calls.  It also tracks who's got priority and can even
> preempt lower priority calls.  Then 10 users try to setup but only the
> emergency worker and the max number the access link can support are allowed
> to complete.  This could actually support Assured Service.  
> 

[MAP] Of course, I would expect any "soft PBX" to think in terms of circuit 
swithing, i.e., it knows that its own access link can support a certain 
number of calls and would reject any more. (Of course, this doesn't help if 
the congestion is at a further point down the path.)

[MAP] Absolutely right. And it would be nice if we could exchange some good 
diagrams af what we are talking about. I for one, have a hard time 
visualizing what someone else is thinking based on their verbal description. 
(I don't know exactly what the configuration was for the subject call from 
Nairobi with thousands of potential competing users. I presume it was a 
router between the thousands of users and the 384 kbit/s sataillite link, so 
it couldn't do CAC.)

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 3 Dec 2002 13:26:27 -0500

On Tuesday, Dec 3, 2002, at 10:28 America/Montreal, [email-masked] 
wrote:
> [MAP] Yes, I understand that 10 independent SIP providers can't know 
> about the link loading in order to decide whether or not to allow a 
> new call to be set up (which is going to "fail" anyway due to bad 
> audio). This is a major shortcoming with SIP and VoIP and IP routing 
> and until it is recognized, admitted, and fixed, it can not be used 
> for real telephone service (much less emergency services).

I consider this an architectural feature.

And I think the main fix is to design and deploy applications that are 
robust in the
real deployed Internet.  Since some have been using VoIP for some years 
now in a
production environment that includes voice/IP/HF Radio (with channel 
fading and
other joys), it seems clear to me that this is entirely possible.  It 
might mean
using codecs other than G.711, and other than ITU-T blessed codecs, 
however,
to give an example.

The Internet has a fundamentally different architecture than the PSTN.  
To run
voice over the Internet, one should adapt the voice application to the 
Internet
architecture rather than insisting that the Internet adopt the PSTN's 
broken
(e.g. no dynamic routing of traffic around fibre cuts) architecture.

I view someone coming to IETF and demanding that the Internet adopt the 
PSTN
architecture to be just as silly as it would be for me to go to ITU-T 
and
demand that the deployed PSTN abandon its design and use the Internet 
architecture.
So far, I've avoided doing the latter by avoiding ITU-T meetings/lists.

Ran
[email-masked]

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 4 Dec 2002 10:03:07 -0800

On Tuesday, Dec 3, 2002, at 10:28 America/Montreal, [email-masked] 
wrote:
> [MAP] Yes, I understand that 10 independent SIP providers can’t know 
> new call to be set up (which is going to “fail” anyway due to bad 

Mike,

I don't need a "SIP Provider" to get telephone services, I just need a 
gateway provider and an Internet connection. These can be unrelated if 
I so desire.  In my case, I am using cliq.com for internet services, 
and deltathree.com for gateway services. While you can certainly decide 
if a technology is suitable for *your* phone calls and only use 
providers that meet your criteria, nobody died and made you king.  
Fortunately for the rest of us, the market gets to decide when the 
Internet *can* be used for real telephone service. In some cases 
various governments will attempt to prevent the market from deciding 
and they will either give up (India) or merely fairly miserably 
(Panama).

thanks,
-rohan