[8626] in Commercialization & Privatization of the Internet

home help back first fref pref prev next nref lref last post

Re: An Open Letter

daemon@ATHENA.MIT.EDU (Larry Walker)
Sat Nov 27 16:22:09 1993

Date: Sat, 27 Nov 93 15:20:20 CST
To: <stpeters@dawn.crd.ge.com>
From: walkerl@med.ge.com (Larry Walker)
Cc: com-priv@psi.com

Dick, et al:

>To: Larry Walker, GE Medical Systems
>
>Larry, Awhile ago you asked me for my analysis of the politics you
>stumbled into on com-priv.  The only thing that seems reasonable is to
>make my response an open letter up for criticism from all sides.  If I
>am successfully evenhanded, I should antagonize just about everyone,
>and I expect I will :-)

Thanks for getting the ball rolling, Dick. As we have discussed in private
email recently, GE Medical Systems is looking at making major use of the
Internet to support its customers and for communication to/from its field
personnel. CDPD (cellular digital packet data) and Internet-via-cable-TV
are the two most promising avenues at present. 

Simultaneously, our customers are demanding high-bandwidth connections
among themselves, and between themselves and others (insurance companies,
for instance). Tele-radiology (in the generic sense of the term) is poised
for rapid growth, but: Health care providers DO NOT want to be in the
networking business. They want single-vendor, turnkey solutions. They do
not want to hear about routing-wars.

>The most basic issue is what the structure of the U.S. portion of the
>Internet should be.  There are two models fighting for dominance, and I
>consider them both badly broken, for reasons that come out by just
>explaining the values that I think important, beginning with:  
>        1. There should be competition at every level.
>        2. What a customer does with a connection should be a matter
>           between customer and provider only.
>Neither of these can ever be perfectly achieved, but that is common to
>all aspects of life; these are ideals toward which to strive, not
>goals we expect to attain.  Such is life.

Yes, this corresponds to the statement I made to you recently regarding my
vision of how the Internet should work: "I send out packets and they get to
their destination. Return traffic gets back to me." I am willing to pay a
reasonable and appropriate price to the provider who "connects me to the
Internet". I do not wish to have to perform an exercise in linear
programming to know what that service will cost me from one provider versus
another. 

>Each of these is also its own paradox.  If  there is to be universal
>exchange, everything must come together at the top.  Where there is
>only one (backbone or exchange - it matters not), there is no
>competition.  If I sell you a pipe, restrictions I put on how you use
>it can imply restrictions on your customers.  The correction for that
>is the first principle - if you don't like my restrictions, you look
>for another provider who doesn't require them.  At the top, this is not
>an option, so a third value is:
>        3. There should be no restrictions at the top.

I would go so far as to say there should be no restrictions, period. I pay
for the pipe that connects me to/from the global "IP cloud". My packets get
to/from anybody else who is connected to the cloud.

Yes, there are significant issues to be addressed in designing an
architecture and accompanying policies, in order to ensure sufficient
incentive that the market will provide the necessary capacity and ubiquity.
But the standard that all proposals ought to be judged against is universal
connectivity and a simple conceptual model from the end-customers' point of
view.

[This morning's New York Times had an article on the increasingly-heated
competition between AT&T, Sprint and MCI for long distance customers. The
biggest problem they cited was customer inertia. I am one of the guilty
inertia-ridden masses: Until I notice that there are clear-cut, large price
differences between carriers, it is way too much hassle to do a detailed
comparison between the carriers' myriad of pricing plans. My time is better
spend arguing over Internet connection policies, eh? :-) But we shouldn't
miss the real point: If a service is confusing to end-customers, they will
tune out the discussion, even to their economic detriment, and certainly to
the detriment of market penetration for a new technlogy.]

>The Internet has always violated this.  For years the NSFNET was the
>only common interconnect, and it has an Acceptable Use Policy that
>prohibits most commercial use.  The growing commercial Internet
>considered this an unacceptable situation, which it clearly was, and
>they countered by forming the Commercial Internet eXchange or CIX.  The
>CIX solved the commercial-use problem, but it imposed its own
>restriction: only traffic travelling originating and terminating on CIX
>members will be exchanged by the CIX.  Traffic is judged not by how it
>got to the CIX, but by where it originated - ans similarly, by where
>its final destination is.  In effect, the CIX set itself up as a judge
>of who is and who is not a network, a very grey area with many
>implications.

To me it is very clear that either 1) the AUP must go away, or 2) the ANS
must no longer be relied upon as "THE" backbone of the Internet. In fact,
the more thought I give to this issue, the more I wonder if the whole
notion of "backbone" isn't the root of the problem. I find myself toying
with the notion that a lattice-structured Internet might reduce/remove this
whole issue. A suffiently richly-connected lattice wouldn't care if Network
A wasn't speaking to Network B; packets could cascade around B via C, D,
E...Z, it would seem. Or perhaps the concept of "backbone" needs to be
supplanted by a "core", supplied by a global ATM switching utility. My
point is that perhaps we are being focused too narrowly in our analysis by
the historical evolution of the Internet.

>Formation of the CIX addressed a real problem.  Unfortunately, the
>providers who formed it chose a solution that fixes only their problems
>while creating new ones of even larger scale for the rest of us.  I'm
>not suggesting this was the intent.  I think they were well-intentioned
>but just didn't think things through enough.
>
>However, forming the CIX also gave them them the power to break the
>Internet, as they have amply demonstrated.  This shows the need for a
>fourth value I had not previously appreciated:
>        4.  The Internet must be free of capricious disruption for any
>            reason.
>

Absolutely!

>Those are the things that I think matter.  There are a lot of others
>that are more like noise in the system.  For example, there is constant
>bickering about government involvement, particularly NSF involvement.
>This is time-honored American politics ... undoubtedly not even just
>ours.  We will wait forever for an Internet if we demand this be solved
>first.  There are questions about whether ANS used its position close
>to the NSF and its status as provider of the backbone to pry customers
>loose from the regionals, its own customers.  Again, whether it did or
>not isn't a big issue except to those directly involved.  What matters
>is that as sole backbone provider it could have.

Again, the "backbone" paradigm seems to be a root problem...

>Before this routing war, I was enough of a CIX advocate to have asked
>Bill Washburn, CIX executive director, for help in convincing GEIS to
>join.  I hadn't really realized the implications of the CIX's members
>only policy, but I think that it could be fixed, from a customer's
>perspective, by simply changing it to say that if a packet arrives on
>a CIX member and leaves on one, it's an acceptable exchange.  I have
>to confess I haven't the foggiest notion what to do about #4.

Well, my simplistic conceptual answer is that we should design the
fundamental architecture of the Internet so that no one party is even ABLE
to capriciously disrupt it...

>--
>Dick St.Peters
>GE Corporate R&D, Schenectady, NY   stpeters@dawn.crd.ge.com

Larry Walker
GE Medical Systems, Milwaukee, WI    walkerl@med.ge.com


home help back first fref pref prev next nref lref last post