Subject: [Ieprep] RE: network congestion, VoIP, NCS contracting approach, etc.

From: "Nguyen, An" <[email-masked]>
Date: Wed, 13 Nov 2002 12:04:47 -0500

Ran,

>Prioritisation is a mechanism.  The NCS mission, as you state, is to
>ensure communications availability.  NCS ought not care which mechanism
>is used, provided that communications remain available.

>Over-provisioning is a different mechanism, commonly used today (max 
>link
>utilisation equal to 30% of link capacity is typical among the ISPs I 
>was talking
>with last Thursday),  to ensure that packets don't get lost in the 
>network,
>because it is cheaper than deploying something like DiffServ.  Other 
>mechanisms
a>lso exist.

Don't know if you are aware of these: GETS has priority trunk queuing for
access and priority egress in addition to HPC. Telecommunication Service
Priority (TSP) provides circuits restorations based on "priority" during an
emergency. 

>[ASIDE:		So far, each time there has been a press release or
article
>claiming that ISP <x> has deployed DiffServ throughout its network, 
>when I
>have tracked down the facts of the matter it has turned out to be 
>marketing
>or press confusion unrelated to the actual operational network.  It 
>would be
>VERY helpful if any ISP would make a public presentation at NANOG/RIPE 
>about
>their deployment.  So if anyone is at such a place and is listening, 
>please
>consider making such a public presentation in detail.]

>An alternative perspective is that NCS ought to focus on talking with 
>ISPs about
>contracts that have *performance-based* metrics for ensuring network 
>availability,
>rather than contracts that require particular mechanisms to be deployed
>(whether or not those mechanisms work in a particular situation).

Reliability for emergency traffic is something NCS would like to work on
next.

>After all, as long as an ISP that has chosen to provide contracted 
>services
>to NCS can provide those services, why should NCS care which 
>mechanism(s)
>are used to provide those services ?

All NCS needs is something better than what non-emergency calls get when
congestions occur to ensure high probability of completion for NS/EP calls.
Under normal conditions, we would not care at all.

Regards,

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

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 13 Nov 2002 09:15:57 -0800 (PST)

> congestions occur to ensure high probability of completion for NS/EP calls.

I think we're zeroing in on the heart of the misunderstanding here.  If
you have something _different_ (which is what you're asking for
when you say "better") than the production path, it will always have a
_lower_ probability of call completion.  You _don't want to be different_
than best-effort.  Different than best-effort is _not-best-effort_.  As I
understand it, your whole focus here is to avoid being not-best!  :-)

    > Reliability for emergency traffic is something NCS would like to
    > work on next.

Wrong order of approach.  You don't want to create a problem and then fix
it.  If you take on reliability first, you'll never create a hole to dig
yourself out of.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 13 Nov 2002 13:04:43 -0500

> congestions occur to ensure high probability of completion for NS/EP 

NCS wants the emergency calls to get through and be intelligible.
This is achievable without adding ANY mechanisms.  In fact, it can
be achieved without providing any different service for NCS than
is provided for other customers -- if the network operator chooses
to engineer their network in that manner.  Many network operators
ALREADY do this.

If NCS would use performance-based metrics RATHER THAN trying to 
standardise
specific mechanisms (e.g. lower drop probability through precedence), 
then
NCS would be able to ensure that the emergency calls get through and
work, operators would not have to go through strange contortions (e.g. 
if
a network drops no packets, then it is impossible for the network
to provide emergency calls with lower drop probability: catch-22), and
taxpayer dollars would probably also be conserved.

An operator who drops no packets cannot provide lower drop probability
OR higher probability of packet transport for NCS.  It is a logical
contradiction.  So the definition you use above penalises operators who
design and operate a network that is better suited for NCS purposes.
That seems like an outcome contrary to NCS's mission as defined in
law and policy.

Ran

---

From: Rex Buddenberg <[email-masked]>
Date: 13 Nov 2002 10:19:12 -0800

On Wed, 2002-11-13 at 09:04, Nguyen, An wrote:
<snip>
> Reliability for emergency traffic is something NCS would like to work on
I believe you have your priorities in the wrong order.  

First, is it ok to translate 'reliability' into availability (up time /
total time) and survivability?  

The engineering solution to the availability problems involve multiple
threading (elimination of single points of failure).  In most cases,
this tends to result in overprovision which overtake the QoS issues.  

I routinely tell my students to tackle the Ao problem _first_; then see
what QoS issues remain.

Existence proof.  The new buoy tenders that USCG is commissioning now
(about half way through the overall procurement) are replacing the
1942-43 tenders.  The sponsor wanted a dynamic positioning system in it
-- take me to an X in the ocean and keep me there while I work the
buoy.  Since we routinely set the buoy next to the rock, this is a
mission-critical exercise properly requiring Ao that cannot be met in a
single-threaded system.  So we spec'd FDDI Dual Attach Stations; the
Juniper class has 6 nodes on an FDDI LAN including the nav sensors on
the bridge, a navigator's workstation and the engine room controller
(wheels and rudder).  
	Every time somebody reviewed and said we needed to do some data flow
analysis, we'd figure out the capacity loads (e.g. a Loran receiver
produces a fix every 4 seconds resulting in 3 dozen bytes of payload),
double everything for redundancy ... and couldn't get above 1% loading
of the network.  End of capacity load analysis.

---

From: "Gary Thom" <[email-masked]>
Date: Wed, 13 Nov 2002 13:26:53 -0500

If there is no distinction, then when there is not enough bandwidth for all
of the _best-effort_ traffic (due to congestion or damage), how does the
emergency traffic get through? Is it ok to just treat it like all the other
_best-effort_ traffic. At this point, doesn't best effort mean you settle
for whatever you can get? Isn't there a way, under these circumstances to
"better" than everyone else?

Gary

> understand it, your whole focus here is to avoid being not-best!  :-)

 --------------------------------------------
 Name   : Gary A. Thom
 Company: Delta Information Systems, Inc.
 Address: 300 Welsh Rd., Bldg 3
          Horsham, PA 19044 USA
 Phone  : +1-215-657-5270 x123
 Fax    : +1-215-657-5273
 E-mail : [email-masked]
 Website: www.delta-info.com
--------------------------------------------

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 13 Nov 2002 10:59:44 -0800 (PST)

> "better" than everyone else?

Only at the expense of likelihood of call completion.  Look at it this
way: Under a pure best-effort situation, you can have four parties sharing
a pie of size forty units, and each will receive a slice of size ten.
Alternatively, under a QoS regime, four parties can share a pie of size
eight, where one gets a slice of size eight, and three others get a slice
of size zero.

If you're the guy who gets priority, and gets to choose which slice to
take, would you rather choose from the set (10,10,10,10) or the set
(8,0,0,0)?  That's what's at issue.  If you FIRST define the overall size
of the pie as 8 (by requiring QoS) and SECOND define yourself as the guy
who gets selection priority, you wind up with a slice (probability of call
success) of 8.  If you FIRST define the overall size of the pie as 40 (by
using the Internet) and SECOND take your fair share, you wind up with a
slice of size 10, and are happier in the long run.

That assumes, however, that the ultimate goal is call success.  If the
ultimate goal is just to feel "special" the other way around works better.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Nov 2002 14:18:01 -0500

You're assuming that the user utility function is linear. It has been 
argued that voice (and video) communications have a step utility 
function: below a certain threshold, there is zero utility. In those 
scenarios, it is indeed more effective to have fewer people each get 
above threshold than all get below the threshold.

As an example, assume that the minimum acceptable bandwidth for usable 
voice service is 10 kb/s (never mind the actual number). Assume 100 kb/s 
total. If 12 people share the bandwidth, each gets roughly 8 kb/s. 
Getting 8 kb/s isn't 80% as good as 10 kb/s, it's useless. Thus, in that 
case, it's better that you tell the two with the least valuable 
communication to wait or send email.

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 14 Nov 2002 01:16:39 -0800 (PST)

> communication to wait or send email.

You miss my point.  The point is that in running QoS in an attempt to be
special, you destroy so much of the resource through fragility that there
isn't enough left for even one user to get a call through.  The resource
here isn't capacity, it's availability.  You guys keep arguing about
capacity, as though it's in short supply, but indestructible, when in fact
the opposite is the case: it's plentiful, but fragile.  The way you make
it go away completely (i.e. no calls get completed at all, regardless of
"specialness") is to complexify the delivery system.  If you don't throw
QoS into the mix, there'll be plenty of bandwidth for everyone.  If you
do throw it in, nobody gets anything.  Simplifying radically for
rhetorical purpose here, of course.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Nov 2002 19:05:45 -0500

On Wednesday, Nov 13, 2002, at 13:26 America/Montreal, Gary Thom wrote:

> of the _best-effort_ traffic (due to congestion or damage),

Did not happen 9/11, does not happen inside the backbone, and ISPs can't
fix the access link -- only the access users can fix *their* links.
No amount of mechanism inside the core can fix the access issues, if any
exist.

Ran

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Nov 2002 20:56:28 -0800

>> No amount of mechanism inside the core can fix the access issues, if any

I completely agree with Ran here. And if there is an issue, it is on
the edge. Dave
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep