Subject: Re: [Ieprep] An alternative concept of IEprep

From: [email-masked]
Date: Fri, 13 Dec 2002 12:35:20 EST

In a message dated 12/12/2002 1:28:27 PM Eastern Standard Time, 
[email-masked] writes:

>    Personally, I find the Japanese deployment of IEprep to be very
> interesting.  Trying to take their concept and generalise it a bit,
> here is an alternative (non-voice) concept for IEprep for discussion.
> 
> Ran
> [email-masked]
> 
> ------------------------------------------------------------------------
> 
> DEPLOYMENT CONCEPT:
> 
>     While dedicated servers are not required for this concept to work well
> and be very useful, dedicated servers could help improve service 
> availability
> and reduce communications latency.
> 
>     A good strategy for the servers would be to build several  
> high-availability
> server clusters.  High-availability meaning that if a component failed,  the
> system could quickly recover and the non-failed components would  continue 
> to
> work together, though possibility with diminished storage, I/O, or CPU
> capabilities.  HA server clusters are widely available COTS products, though
> they are often not cheap.
> 
>     Clusters would be placed in ISP co-location facilities, preferably in 
> the
> same bunker-style facilities used for the ISP's core routers.  The goal 
> would
> be to have at least one server cluster inside each large ISP's core.  
> Contracts
> could be signed with the ISPs to give service restoration to those  clusters
> priority -- and if co-located in the ISP's core router POPs, there is high
> probability that the ISP could get technical staff on site quickly if 
> needed.
> Being inside an ISP's core router POP also helps ensure service 
> availability,
> because the server cluster could easily have redundant connectivity to  
> 

[MAP] This would certainly be a good idea and needed to support an IAA type 
service, but I wonder several things:

Wouldn't much of what is described be the characteristics of the ISP's core 
routers anyway?

How would a user get "priority" to reach one of the (several) clusters? In 
the GETS model, one only has to reach a nearby switch that understands GETS 
to get "priority" for the rest of the call setup. (One comment was that 80% 
of the lines in the US are so equipped.)

Mike Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 13:19:52 -0500

On Friday, Dec 13, 2002, at 12:35 America/Montreal, [email-masked] 
wrote:
> In[MAP] This would certainly be a good idea and needed to support an 
> IAA type
> Wouldn't much of what is described be the characteristics of the ISP's 
> core routers anyway?

	Hmm.  Sorry I was confusing.  Not exactly sure which bits I messed up 
on,
but I'll give it a try.  When I gave details about HA, I was talking 
about a server
in the sense of like an IBM AIX box (or a Sun Solaris server or 
whatever brand)
-- to host whichever applications (e.g. web, email, IRC, or whatever).  
Apologies
if I got that confused with an ISP's core router, which as you say, 
might have HA
properties for its own reasons.

	If this is not clear or I've answer the wrong question, let me know 
what
is unclear and I'll try again.

> How would a user get "priority" to reach one of the (several) 
> clusters? In the GETS model, one only has to reach a nearby switch 
> that understands GETS to get "priority" for the rest of the call 
> setup. (One comment was that 80% of the lines in the US are so 
> equipped.)

	That scenario description was not so much trying to "solve" the 
"priority" issue,
as to come up with candidate applications that are useful and also work 
well even
during congested or low-bandwidth or other unhappy operating 
conditions.  That is,
these are things that might still work in operating environments where 
some/all
voice codecs might not work well in.

	The same (router CoS/filtering/CBQ, switch CoS/filtering/CBQ) 
mechanisms
can be used for access links.  The one good thing here about IP-layer 
or link-layer
mechanisms is that they can work for any sort of traffic.  If there are 
a small
number of such server clusters, then one might be able to get dedicated 
access
link preference for all traffic to/from those clusters.  (The downside 
of deploying
it in that manner is that it would also give preference to any traffic 
from a
bad guy trying to reach those servers, so security issues remain.)

	In the core, the only thing I was proposing would be that ISP A and 
ISP B
would each have contracts with NCS (or whoever) that gave restoration 
of service
between that ISP's core and the co-located server cluster priority and 
that the
core links inter-connecting A's core and B's core also get priority 
restoration.
Within a given core, the concept was relying on the usual 
over-provisioning strategy.

(MORE GENERICALLY, NOT TIED TO THIS CONCEPT, ...)

	An advantage of the PSTN is that maybe 10K to 30K POTS lines terminate
in a single device (Class 5 switch) and control is centralised in that 
device.
I can't think of any deployed router that has 10K tail circuits 
attached to it
(or even close to that).  And control is de-centralised, so each end of 
the circuit
has some control.

	The typical ISP T1/E1 deployment topology (with ISP router on one end 
and
a customer router on the other end) looks somewhat like a Class-5 
switch connected
via a T1 or ISDN PRI to an over-subscribed corporate PBX than like a 
POTS line
to a house.  What is the GETS strategy when the phone is behind a 
corporate PBX
and that PBX has more offered load in outbound call attempts than it 
has capacity
to connect to the Class-5 phone switch ?  Does NCS have a special 710 
contract
with most corporate PBX owners ?  Is it just best effort in that case ? 
  I'm curious.
And what about PBXs that haven't been configured to know about 710 at 
all ?

Ran
[email-masked]

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