(ASCEND) Port reselling: TCP modem.

[Will Pierce test acct <willp2@dreamscape.com>]

Howdy all,

I haven't been on the list in a long time.  Since there's been some recent
flareups about Ascend's code quality and all, I'll share my own recent
experiences.

In the past year, our parent company has deployed two DMS 500 switches in
our primary POP locations.  We're up in Bell Atlantic (formerly Nynex)
territory, where the cost of channelized T1's and PRI's is ridiculous.

With our DMS 500's, we now take trunks directly from Bell Titantic and
then feed them to our switches and then pull out PRI's to our base of Max
40xx's.

Let me say this: PRI's totally and completely blow channelized-T1's out of
the water for speed and reliability of connections.  Our percentage of
disconnect codes has moved the code 45 percentage up to about 80%.  (code
45 means the user requested disconnect.  I call it an "OK" in our call
logs.) Speeds have also rose about 5% for everyone.  People in the boonies
who always got 26.4k now get 28.8 or 31.2k.  The highest speeds we see are
now 54.7k.  And some people get 54.7k _every_ time without fail.

Now for the gripes:

7.0.3 is totally unstable for us.  We use ISDN with NFAS to double-up two
wan ports on one D-channel.  When a clean (fclear,nvramclear in diag) max
4048 with _no_ settings is configured for ISDN_NFAS to an NTI switch, the
box reboots continuously.  I have not had the same problem with 7.0.4, but
I am understandably nervous about moving the ones at 7.0.1 to 7.0.4.

We recently realized that we have had more max 40xx's go belly up due to
power supply problems than we have had modem cards die.  It's one reason
we are extremely nervous to consider a TNT.

Now for something _totally_ cool!

TCP Modem is the most awesome thing I have overlooked.

For the uninitiated:  "TCP Modem" in the Max allows you to specify a TCP
port that you can connect to and the connection is treated exactly the
same as if you dialed in.  Same PPP Delay, same login prompt, you can
start up PPP over the TCP connection and it works beautifully.

There was a somewhat obscure section in the RADIUS manual that I ran
across recently where you do this:

Set up a user to authenticate with DNIS (dialled number).  For example,
you have a single Max pool with PRI's (so you get DNIS on every call).
You have one dialup number: 212-555-5656.  Let's suppose you have a
"sister" ISP in upstate New York whose access number is 315-555-1111.
Both you and the "sister" ISP configure TCP modem on port 150 (or 6150 or
whatever) on _all_ of your maxes.

Then, the 212 area code ISP gets their switch to put in 212-555-1111 in as
a new number that points at the huntgroup.  Then you configure a
connection profile to authenticate by DNIS _only_, and set it up to open a
TCP-Clear connection to a max in area code 315 (over the internet) to port
150.

This means anyone dialing 212-555-1111 will be connected immediately to an
Ascend Max in area code 315, but the packets are going over the internet--
no long distance charges.

Let's say the 315 area code ISP also sets up a connection profile and a
number for 315-555-5656 to open a TCP-Clear connection to a max in area
code 212 on port 150.

This means that the ISP in 212 now has a dialup number in area code 315
and the 315 ISP now has a dialup number in area code 212.

This is beyond what iPass provides.  Actually far beyond.

Instead of having customers (with iPass) dial up another ISP, and use a
slightly modified DUN entry, and a modified RADIUS authentication daemon
which proxies out authentication on iPass calls-- this means that there is
no iPass middle-man.  Two ISPs in different geographic regions can provide
dialup access to each other and be able to provide tech support for
customers in those cities just the same as if they had dialed in locally.

The benefits:
 * customers hitting a TCP-tunneled access number get the same IPs and
RADIUS filters/idle timeouts/etc as if they hit a local number
 * because the TCP tunnel is from Max to Max, it is far easier to
troubleshoot routing problems between ISPs.  Assuming both ISPs are
BGP-speakers, in a worst-case scenario, weights can be applied to the
routes that provide the best round-trip-time, on both ends.
 * there is no equipment outlay for expanding, and no need to provide a
POP for those cities.

The downside:
 * the bandwidth of a caller who hits a "TCP tunneled" access number is
weird: a customer who downloads 1 megabyte actually gets 1 megabyte from
the internet connection of their real ISP.  This 1 megabyte is then sent
_outgoing_ from that ISP to the ISP that is providing the remote access
number.  So, instead of having to worry about bandwidth in mostly only one
direction, any incoming bandwidth to a dialup customer on a
remote-TCP-city (what the hell do you call this?) will actually be using
roughly equal in/out bandwidth.  (Assuming that they only surf and aren't
getting their data primarily from their real ISP's servers.)  This
actually wouldn't be as much a consideration if all customers were proxied
or there was a transparent cache somewhere at their real ISP.
 * Someone would have to figure out how to charge for this service.
 * You can't have more people connected to a max with TCP connections than
you have IPs in your dialup pools.
 * A single max 40xx can handle 48 dialup callers just fine without CPU
loading problems.  How many additional TCP connections can it handle
before running into loading problems?  I don't know.  The Max with a TCP
Modem connection has to handle PPP encapsulation, MS-Stac compression
(if enabled), any packet-filtering specified in the RADIUS profile, and of
course it has to handle the packet-routing.
 * Don't even ask me if Multilink with Stacking will work over TCP Modem.
I've got enough to think about. :)
 * Accounting for _who_ sent you a call by TCP-Modem can be difficult.
If you had multiple people providing dialup->tcpmodem service, you'd have
to receive the logs of connect start/end times and line it up with calls
in your own log to verify calls.  I'm still playing with how the RADIUS
accounting would work between two providers. And how to turn this into
something usable for possible billing purposes.

Some ideas:
 * With DNS load-blancing, you could specify "tcpmax.domain.com" to
resolve to each IP address of each Max that you want to accept TCP-Modem
connections.  Then on the remote ISP's connection profile, you specify a
hostname of "tcpmax.domain.com" instead of an IP.  This would balance the
load of TCP-modem callers across a pool of Maxes.  This would also be
manageable by the right people- at domain.com instead of the remote ISP.
(Sorry if this is real confusing.)

Why do this?

  Well, it wouldn't make sense to use this as a way of _truly_ expanding
into other markets in any kind of large or medium scale.  If you have
1,000 customers who all connect to you this way, you should get your own
POP.

  It does make sense when two ISPs have customers who travel between their
coverage areas.  Or two ISPs that do not have plans to expand into each
other's territories.  If the two ISPs end up with many customers using
these access methods, it might even make sense to bring up a Frame Relay
link between the ISPs to handle the traffic between Maxes exclusively.

  If both ISPs are CLEC's and recip comp is a revenue source, then it
makes more sense for two ISPs to collect each other's recip comp than to
have their customers hang on to an AOL account for the times when they
travel outside their ISPs coverage area.

  It may cost some ISPs to get additional phone numbers configured to hunt
into their Maxes.  This cost might be unbearable.


If someone has had this idea before, or if it is already a developed
system being used by many ISPs that I'm just ignorant of, please please
please give me the pointers to the resources on the net.

I'm a little uneasy just now about how the charges would be calculated.
But I'd be very excited if there was a webpage where ISPs could advertise
that they provide this service, including what areacode/exchanges for each
city, and their own costs on setup and any per-hour costs.  That would be
under the assumption that there are no problems with CPU loading, and no
problems with bandwidth that I've overlooked.  

There are probably many other ways to do this, involving RADIUS proxying,
or encrypted tunnels that I haven't mentioned or thought of.

-- 
Will Pierce
System Administrator
Dreamscape Online, LLC.
willp@dreamscape.com

++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>