The CIX and the NSFNET regionals - a dilemma

Martin Lee Schoffstall schoff at
Wed Feb 5 16:21:46 UTC 1992


I've had retail service customers since 1985, i have had user's groups
meetings 3-4 times a year since 1986, I know who pays the bills, and I
don't have a big university to back me if I fail, or a government agency
to pay me regardless if it works.  Trust me, I'm properly motivated.

I don't think I pooh poohed VAF, in fact I didn't even respond to his
posting yet, so relax your over-reacting.

John Curran's posting from nearnet says that my tremendously detailed
engineering solution called "tuning" (see my upcoming paper in IEEE
Networks) works for 115 - 20 of his organizations.  That's not too bad
given the big R&D budget of the last few days.

I kind of disagree on the need for an immediate DAMN good answer,  given
the many upcoming changes I see 3-4 answers over the next 18months as
things evolve.  And I see them being done cooperatively with little
in the way of emotion or rancor.


PS:  despite the intensity i do appreciate the statement that you believe
	that I'm doing my customer a service by using the CIX.
 > From: Martin Lee Schoffstall <schoff at>
 > Subject: Re: The CIX and the NSFNET regionals - a dilemma 
 > Date: Tue, 04 Feb 92 22:47:42 -0500
 > I've deferred responding publicly to the com-priv message since I hoped
 > others would.  But I will respond to this....
 > there isn't a routing "problem".   there are gigapackets/month running
 > through the CIX reliably, with little latency, and very inexpensively.
 > What vaf wants is some tuning for the high bandwidth path that he and
 > a very few others have by the grace of nsf and tax $'s.  it is a
 > reasonable request given that people don't want to ante up quite yet
 > for t3 cix interconnects.  This tuning to my knowledge is driven
 > by a fairly small % of the total CIX networks (10 out of 500?).
 Right now the performance of the NSFnet is pretty bad (even the T3
 network performance is worse than a CIX provided connection) so you
 are probably doing your customers a service by using the CIX to route
 packets instead of the NSFnet.  But let's look into the future where
 ANS finally gets its technical act together and the T3 NSFnet really
 starts to hum.  Add in much greater use of the CIX and I can see an
 inverted picture where the CIX is more of a bottleneck than the
 Let me bring this closer to home for you.  The federal government is
 paying to provide a T3 network for research and education.  I suspect
 that NYSERnet is intended to be a beneficiary of this service.  I also
 presume that PSI is still the carrier for NYSERnet (please correct me
 if I am wrong).  In that case, by running traffic through the CIX you
 are circumventing a federal resource.  Not a problem now but what if
 the NSFnet gets its act together?  In that case you, PSI, will be
 doing your clients who may legitimately use the NSFnet, a GREAT
 disservice.  Were I them I would become POWERFULLY annoyed.  How are
 you going to deal with the problem then?
 Bottom line here Marty is that you and every other service provider
 who carries both CO and RE traffic had better have a DAMNED good
 answer to this problem.  I would recommend you begin to think about it
 NOW.  I have been harping about dropping AUPs on the NSFnet but that
 is unlikely to ever happen so we are going to have to live with the
 Now one last item: don't get on Vince's case.  He has been tasked with
 solving a problem and he is doing his best.  He has identified a
 problem that clearly ought to be dropped in your lap (collective
 "your" because I suspect that CERFNet and possibly UUnet/Alternet are
 in the same boat).  Perhaps you ought to say "thank you" and work with
 him instead of pooh-poohing his posting.
 Brian Lloyd, WB6RQN                                     Lloyd & Associates
 Principal and Network Architect                         3420 Sudbury Road
 brian at                                         Cameron Park, CA 95682
 voice (916) 676-1147 -or- (415) 725-1392

More information about the NANOG mailing list