Subject: Re: [Ieprep] any commercial usage for "emergency QoS"?

From: [email-masked]
Date: Wed, 27 Nov 2002 12:35:18 EST

In a message dated 11/26/2002 9:50:17 PM Eastern Standard Time, 
[email-masked] writes:

> So the demo might be an existance proof that VoIP works fine over
> a set of best-effort IP networks across 2-3 continents ?
> 
[MAP] And there's never been an argument that the quality isn't good when the 
network is not overloaded and there are no major faults anywhere. What some 
on this discussion have not yet understood, is that we are trying to talk 
about "preparedness" for a traffic overload/fault condition that has never 
occurred. It did not occur on Sept 11 or in the "Baltimore Train Tunnel". 
Whether some like it or not, that is the mission of both NCS and DoD - 
preparing for what we hope never happens.

Yes the demonstration was interesting, but completely irrelavent to the task 
at hand.

In fact, I have a question about that demonstration. If I understood the 
explanation, the end user in Nairobi was using a 128 kbit/s interface which 
went to something where he was then sharing a 384 kbit/s interface to get to 
the Internet backbone with, what I thought I heard quickly mumbled, was 
"thousands of users" (who were mostly asleep). Obviously, the results would 
be very much different if a lot of those other sleeping users were also awake 
and trying to make voice calls, like if there were a major disaster.

In addition, I do not consider a call made on a speaker phone and broadcast 
over a PA system as being a sufficient demonstration of the effect that the 
round-trip delay would have on a normal conversation.

Another question: Was it stated during the presentation that the packet loss 
ratio was 40%? Whatever the loss ratio, why are packets lost? Is it because 
of congestion at some point (and discard because the buffer is full)?

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 27 Nov 2002 09:50:12 -0800 (PST)

On Wed, 27 Nov 2002 [email-masked] wrote:
    > We are trying to talk about "preparedness" for a traffic
    > overload/fault condition that has never occurred. It did not occur
    > on Sept 11 or in the "Baltimore Train Tunnel".

Right, so those were both examples of complete disconnection.  What's the
condition that you believe has never occurred?  Can you define it for us?
We're engineers; if you can define a problem, we can try to solve it.

                                -Bill

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 29 Nov 2002 17:28:52 -0500

On Wednesday, Nov 27, 2002, at 12:35 America/Montreal, [email-masked] 
wrote:
> [MAP] And there's never been an argument that the quality isn't good 
> when the network is not overloaded and there are no major faults 
> anywhere. What some on this discussion have not yet understood, is 
> that we are trying to talk about "preparedness" for a traffic 
> overload/fault condition that has never occurred. It did not occur on 
> Sept 11 or in the "Baltimore Train Tunnel". Whether some like it or 
> not, that is the mission of both NCS and DoD - preparing for what we 
> hope never happens.

The Baltimore Train Tunnel was unquestionably a major fault.  It cut a 
whole
lot of fibres from a whole bunch of different fibre networks.

Similarly, a LOT of fibre was cut in lower Manhatten on 9/11, and in 
Kobe,
and in Northridge during that earthquake.

In each of these cases, the Internet just kept working, routing around 
the
massive fibre damage.  So claiming that "a fault condition has never 
occurred"
is just factually wrong.

Lack of "traffic overload" is not an accident, but the result of good 
network
engineering by professionals at a lot of different organisations.

> Obviously, the results would be very much different if a lot of those 
> other sleeping users were also awake and trying to make voice calls, 
> like if there were a major disaster.

Probably not asleep at 8pm.  Also, email/web/etc are TCP-based 
applications,
so would naturally back off when confronted with a non-responsive UDP 
flow
(e.g. VoIP).

> In addition, I do not consider a call made on a speaker phone and 
> broadcast over a PA system as being a sufficient demonstration of the 
> effect that the round-trip delay would have on a normal conversation.

I'd bet that a demo could be arranged between US east and west coast 
from the
NCS/DISA offices -- main question would be whether an Ethernet port 
outside
the sundry firewalls/NATs could be obtained since VoIP doesn't work 
well through
firewalls/NATs.  If NCS/DISA folks are interested in this, I'd suggest 
dropping
me and Bill and note.

And exactly *what* demonstration parameters would be sufficient in your 
view ?
You've said the Atlanta ones were not, but have not indicated which 
test parameters
are sufficient, making it hard for anyone to meet your spec.

> Another question: Was it stated during the presentation that the 
> packet loss ratio was 40%? Whatever the loss ratio, why are packets 
> lost? Is it because of congestion at some point (and discard because 
> the buffer is full)?

No one has questioned that congestion is a potential issue on access 
links.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 30 Nov 2002 06:18:19 -0800 (PST)

> packet loss ratio was 40%?

Four people measured loss between 27% and 30% during that call.  Henning
measured 0%, and then subsequently amended that to, I believe, 7%.  30%
loss is typical on the connection to the phone in Nairobi, sometimes
lower, sometimes higher.

    > Whatever the loss ratio, why are packets lost? Is it because of
    > congestion at some point (and discard because the buffer is full)?

The simple answer is that they're discarded because they weren't paid for.
There are several thousand 128K DSL circuits terminating on a 384K
satellite link there, which means, in ISP-speak, about a thousand-to-one
subscriber ratio, which is one order of magnitude higher than you'd
typically find here in the States, for instance.  If they could afford to
pay ten times more for their service, which they can't, because it's not a
wealthy country, they'd receive service comparable to that which we
recieve here.  To put things in perspective, if you were in Korea, your
service would be as much better than US service as US service is than
Kenyan service.  So there's certainly a lot that can be done if the
government wanted to improve the quality of service, rather than mandate
QoS.

Another way to look at it is that the everyday operating conditions in
Kenya simulate what the Internet would be like here in the U.S. if 90% of
it were offline due to a disaster or something.  Or if ten times as many
people were all trying to use it simultaneously.  Which is one of the many
reasons we're so interested in putting phones in developing countries.

                                -Bill