Xref: utzoo comp.protocols.iso:1536 comp.protocols.tcp-ip:14788
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!lvs.Eng.Sun.COM!karl
From: karl@lvs.Eng.Sun.COM (Karl Auerbach)
Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip
Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25
Message-ID: <7566@exodus.Eng.Sun.COM>
Date: 7 Feb 91 19:16:11 GMT
References: <38836@cup.portal.com>
Sender: news@exodus.Eng.Sun.COM
Followup-To: comp.protocols.iso
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 42

In article <38836@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>I would like to get opinions on pros and cons for setting up an
>Internet.  The two setups are:
>
>1) All sites on the internet have routers that attach to a public
>data network, like UUNET's Alternet, and use TCP/IP to communicate
>between nodes on the net.  To the extent that X.25 might be used
>underneath TCP between the routers, this is invisible to the
>applications.
>
>2) All sites on the internet connect directly to an X.25 network,
>and any client-server applications between two sites are written
>directly to an X.25 API or to some software abstraction that is
>written on top of X.25.
>
>What are the advantages to either approach?  Clearly 2) is going
>to be more efficient since you don't have the extra error-checking
>of TCP and you don't have the extra data bandwidth of the router
>headers being attached to each packet.  This advantage aside, are
>there any decisive advantages that argue for approach 1)?

Don't bet on approach #2 being automatically more efficient.  A router
can run a number of parallal X.25 connections and spread the traffic
across those.  (You may find some X.25 providers will constipate a
given X.25 virtual circuit well before you exhaust the interface
circuit bandwidth, so by using multiple VCs you can push more
packets.)

And I doubt that you will reach data rates over the typical X.25 (or
TCP or OSI over X.25) that will even begin to make the TCP/IP or OSI
checksumming, etc increase to a noticable level.  (This is not to say
that some networks may offer high performance X.25 service.  It's just
that most of the providers that I see don't.  If they did then your
overhead concern would begin to be meaningful.  But I suggest that you
might find that the burden of dealing with X.25, even at low data
rates, greatly exceeds the cost of TCP/IP or OSI connectionless
network and transport layer.)

Approach #1 will give you more portable code (assuming you are
programming to a fairly standard interface like "sockets".)

				--karl--