prc@erbe.se (Robert Claeson) (09/07/89)
I'm completely new to X.25, and need to know more about it. I've been
able to get enough information to know that X.25 has three layers,
of which the top-most handles the addressing. What I haven't been
able to get into my poor head is the difference between X.3, X.28 and
X.29, and what services an X.25-based network provides. For example,
does X.25 only define raw circuits, or are there multiple types of
circuits (for, say, e-mail, remote login and file transfer)? I can
almost guess that X.400 is the X.25 so-called application-layer
protocol for e-mail. I believe that the combination X.3/X.28/X.29
does the same for remote login, but does it define a virtual terminal
like ISO VT, or is is more like rlogin over TCP/IP? In other words,
do I still need a 3270 emulator for my VT220 to use X.25 to connect to
an IBM mainframe with an X.25 interface?
Please enlighten me, if you think that you can.
--
Robert Claeson E-mail: rclaeson@erbe.se
ERBE DATA ABhaas@wasatch.utah.edu (Walt Haas) (09/08/89)
In article <796@maxim.erbe.se>, prc@erbe.se (Robert Claeson) writes: > I'm completely new to X.25, and need to know more about it... Well it's been several years since I wrote my X.25 implementation... let me blow the dust off these books... *poof* KERCHEWWW!! ok, now: > What... is the difference between X.3, X.28 and X.29... These three protocols are users of X.25 services. They are closely related protocols which provide virtual terminal service. The human user of this lot has a dumb terminal connected to a device called a Packet Assembler/ Disassembler (PAD) which collects keystrokes into packets for transmission to the host, and turns packets from the host back into characters for the terminal. The PAD may be either a discrete piece of hardware like a TAC or a program which runs like a TELNET client. The PAD executes various algorithms in determining when it has enough keystrokes to forward a packet, and so on. These algorithms are controlled by a collection of parameters known as "PAD parameters". X.3 specifies what a PAD does, what its PAD parameters are and what values they may take on. X.28 specifies how a terminal and its human user interact with a PAD. X.29 specifies how a PAD talks over an X.25 interface to a remote host about the user's virtual terminal session. > and what services an X.25-based network provides. X.25 is a standard by which a host talks to a network; the actual internals of the network are not specified, and various networks have substantially different internals. But the X.25 standard defines reliable data transmission over virtual circuits, with a means of addressing, much as TCP/IP does. > For example, does X.25 only define raw circuits, or are there multiple > types of circuits (for, say, e-mail, remote login and file transfer)? The two types of virtual circuits are Permanent and Switched. When a Switched Virtual Circuit is established (by a Call Request packet) one of several parameters of the call is the protocol to be spoken during the call. > I can almost guess that X.400 is the X.25 so-called application-layer > protocol for e-mail. Basically you have the right idea, but it would be more correct to state it that "X.400 is the CCITT protocol for e-mail and one possible user of X.25 services." > I believe that the combination X.3/X.28/X.29 does the same for remote login, > but does it define a virtual terminal like ISO VT, or is is more like > rlogin over TCP/IP? I'm not familiar with ISO VT (did they finally produce a standard?) and the X.3/X.28/X.29 standard has no doubt evolved since I implemented it, but as I recall it has many of the features of rlogin (not, however, the ability to pass username, terminal type or window size). > In other words, do I still need a 3270 emulator for my VT220 to use X.25 to > connect to an IBM mainframe with an X.25 interface? Depends on the interface - in many cases, your X.25 connection to the IBM will actually be a connection to a PAD connected milking-machine fashion to a 7171 controller, thus: you - terminal - PAD ========= PAD - 7171 - IBM host X.25 In this case perhaps the 7171 will provide the necessary emulation. Hope some of this helps... hope it's not too out of date! Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas
epsilon@wet.UUCP (Eric P. Scott) (09/09/89)
In article <3279@wasatch.utah.edu> haas@wasatch.utah.edu (Walt Haas) writes: > But the X.25 standard defines reliable data >transmission over virtual circuits, with a means of addressing, much as >TCP/IP does. It doesn't meet the Internet's definition of reliable. If you don't want to see your VCs reset everytime someone sneezes, you should run a truly reliable protocol (e.g. TCP) on top of X.25. (This also addresses all the concerns of the original query.) -=EPS=-
jordan@Morgan.COM (Jordan Hayes) (09/11/89)
Eric P. Scott <epsilon@wet.UUCP> writes: Walt Haas <haas@wasatch.utah.edu> writes: But the X.25 standard defines reliable data transmission over virtual circuits, with a means of addressing, much as TCP/IP does. It doesn't meet the Internet's definition of reliable. If you don't want to see your VCs reset everytime someone sneezes, you should run a truly reliable protocol (e.g. TCP) on top of X.25. Remember, ``Point-To-Point'' is not ``End-To-End'' ... (hi map!) Of course, VCs are "reliable" but not end-to-end ... /jordan
haas@wasatch.utah.edu (Walt Haas) (09/11/89)
In article <522@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >In article <3279@wasatch.utah.edu> haas@wasatch.utah.edu (Walt Haas) writes: >> But the X.25 standard defines reliable data >>transmission over virtual circuits, with a means of addressing, much as >>TCP/IP does. > >It doesn't meet the Internet's definition of reliable. If you >don't want to see your VCs reset everytime someone sneezes, you >should run a truly reliable protocol (e.g. TCP) on top of X.25. Unfortunately the Internet's definition of "reliable" isn't reliable, since the TCP layer gives no notice at all when the route to the remote host goes down. Bear in mind that TCP is a military protocol designed primarily for an environment in which a hostile enemy is shooting holes in the network, and many compromises are forced on TCP users in order for the protocol to meet this goal. In the world of commercial applications that most of us work in, the environment and requirements are far different from the military world. The massive inefficiencies forced by using military protocols for everything regardless of the environment would preclude TCP/IP from civilian use if the government didn't heavily subsidize its use. -- Walt Haas haas@cs.utah.edu utah-cs!haas
amanda@intercon.uu.net (Amanda Walker) (09/12/89)
In article <3290@wasatch.utah.edu>, haas@wasatch.utah.edu (Walt Haas) writes: > Unfortunately the Internet's definition of "reliable" isn't reliable, > since the TCP layer gives no notice at all when the route to the remote > host goes down. The only layer that should care or know about routing is the layer that actually does it (IP, in this case). A program that uses the services of a given level should not know what's going on in different levels. For example, somthing that uses TCP should not *care* if the IP level has to switch routes, or wait for a gateway to reboot, or whatever. Virtual circuits are good models of wires. They are not good models of packet delivery. "Reliable" in the TCP sense means that (a) if it can get there, it'll get there, (b) it'll only get there once, and (b) you'll know it got there, even if things happen along the way. I'd rather have my network cope with difficulty than to throw up it's hands and give up :-)... This is why, in a TCP/IP environment, X.25 is only useful as a way to route unreliable datagrams to another point. > Bear in mind that TCP is a military protocol designed > primarily for an environment in which a hostile enemy is shooting holes > in the network, Or lightning strikes, power outages, momentary failures, congestion. These things do happen in the real world. > In the world of commercial applications > that most of us work in, the environment and requirements are far different > from the military world. This is only true in trivial cases. Assuming the best, especially in a data communication environment, is a strategic mistake. Things go wrong, even on the best of networks. Life is like that. Gateways can still crash. Backhoes can still cut through fiber optic cables. Lightning can still strike satellite dishes. Squirrels can chew through phone and power lines. > The massive inefficiencies forced by using > military protocols for everything regardless of the environment would > preclude TCP/IP from civilian use if the government didn't heavily subsidize > its use. What's so inefficient about TCP/IP in civilan use? I mean, especially compared to, say, ISO OSI... It works, it's fast, it has survived the test of time. -- Amanda Walker amanda@intercon.uu.net | ...!uunet!intercon!amanda
mhw@wittsend.lbp.harris.com (Michael H. Warfield (Mike)) (09/14/89)
In article <3290@wasatch.utah.edu> haas@wasatch.utah.edu (Walt Haas) writes: <Original two articles deleted> >Unfortunately the Internet's definition of "reliable" isn't reliable, >since the TCP layer gives no notice at all when the route to the remote >host goes down. Bear in mind that TCP is a military protocol designed >primarily for an environment in which a hostile enemy is shooting holes >in the network, and many compromises are forced on TCP users in order >for the protocol to meet this goal. In the world of commercial applications >that most of us work in, the environment and requirements are far different >from the military world. The massive inefficiencies forced by using >military protocols for everything regardless of the environment would >preclude TCP/IP from civilian use if the government didn't heavily subsidize >its use. Point #1 - If a host becomes unreachable, TCP certainly does notify you. The fact that routers underneath you may change your route, if one route becomes unusable, I would certainly call desirable in commercial environment. At first glance this would appear to be more efficient than restarting a session from scratch as the situations on a complex network shift. TCP is a "connected" service protocol. As long as it can maintain the connection, through whatever route, it is doing is job. And it most certainly does notify you when a connection goes down. Point #2 - Calling tcp/ip a military protocol is a misnomer at best. TCP/IP was not designed to "military spec". Rather the DoD specifications are based on the Internet (ARPA net) "RFC" specifications. These were largely developed in the university environment. While it is true that the universities have a large interest in military contracts, ARPA net developed around the needs of the computing community of the universities. The "openness" of the tcp/ip type protocols and their lack of security is hardly within normal military interests. The DoD specs, which parallel the Internet RFC's, even have a disclaimer that, if there is any discrepancy between the DoD spec and an Internet RFC, that the Internet RFC holds precedence as is assumed to be the authoritative document! When is comes to true military specification, the word of the military is God and nothing holds precedence over the military spec. Point #3 - Blaiming TCP/IP inefficiencies on the military is pure BULLSH*T! There is still a debate on the subject, but many consider OSI even WORSE as far as network efficiency goes. The techniques and structures of OSI take many of the principles behind TCP/IP to extremes. And our military had absolutely nothing to do with its design. TCP/IP's wide spread use is due to the fact that it is a large multivendor standard, not because the military has subsidized it. Does the "gossip" specifications (requiring eventual convertion to OSI in government) mean that the OSI protocols were writen to military spec or that the military has somehow subsidized the Europeans? Hardly! The TCP/IP protocols were designed to operate over absolutely trashy networks by todays standards. You might think that as network technology has advanced that the overkill in network protocol principles would evolve into simpler methods. Unfortunatly OSI has proved that such is not the case. I would cringe to think of a network protocol truely developed to military specification. It would, no doubt, be hugh and inefficient. However, unlike TCP/IP, I doubt it would work and I doubt the civilian population would be interested in it. ---- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
dennis@virtech.UUCP (Dennis P. Bednar) (09/16/89)
In article <522@wet.UUCP>, epsilon@wet.UUCP (Eric P. Scott) writes: > In article <3279@wasatch.utah.edu> haas@wasatch.utah.edu (Walt Haas) writes: > > But the X.25 standard defines reliable data > >transmission over virtual circuits, with a means of addressing, much as > >TCP/IP does. > > It doesn't meet the Internet's definition of reliable. If you > don't want to see your VCs reset everytime someone sneezes, you > should run a truly reliable protocol (e.g. TCP) on top of X.25. > (This also addresses all the concerns of the original query.) > > -=EPS=- This is correct. X.25 is specified as a protocol between a DTE (packet switching host) and a DCE (IMP or interface message processor a.k.a. packet switching node). While X.25 level 2 (the lowest protocol layer) has reliability built into it (checksums, acks, retransmissions, sequenced packets), the reliablility is only between the host and the IMP. There is no guarantee of end-to-end reliablity between two hosts: (local) (local) (remote) (remote) DTE DCE DCE DTE host <---> IMP <---> IMP <----> host In other words, when the local DTE on the left sends a level 3 DATA packet and receives a level 3 RR acknowledgement packet from the local IMP (on the left side of the above diagram), it only means that the local IMP has acked the packet, but not necessarily that the remove DTE in the right side of the figure has even received it. The virtual circuit could be closed or torn down by the portion of the network between the two IMPs shown above before the DATA packet reaches the remote DTE. What you need is a layer 4 transport protocol that speaks end-to-end (host-to-host) for the extra end-to-end reliability not provided by X.25. There are two ways to layer TCP over X.25: TCP/ IP / X.25 level 2 TCP/ IP / X.25 level 3 / X.25 level 2 The second way is the DDN interface specified by the Defense Department. -- Dennis Bednar uunet!virtech!dennis (703) 430-9247 Virtual Technologies Inc, P.O. Box 876, Sterling VA, 22170
jwb@cit5.cit.oz (Jim Breen) (09/18/89)
In article <1167@virtech.UUCP>, dennis@virtech.UUCP (Dennis P. Bednar) writes:
*
* This is correct. X.25 is specified as a protocol between a DTE
* (packet switching host) and a DCE (IMP or interface message
* processor a.k.a. packet switching node). While X.25 level
* 2 (the lowest protocol layer) has reliability built into it
* (checksums, acks, retransmissions, sequenced packets), the
* reliablility is only between the host and the IMP. There is no
* guarantee of end-to-end reliablity between two hosts:
*
* (local) (local) (remote) (remote)
* DTE DCE DCE DTE
* host <---> IMP <---> IMP <----> host
*
* In other words, when the local DTE on the left sends
* a level 3 DATA packet and receives a level 3 RR acknowledgement
* packet from the local IMP (on the left side of the above
* diagram), it only means that the local IMP has acked the
* packet, but not necessarily that the remove DTE in the
* right side of the figure has even received it. ..........[etc]
Full 1984/1988 X.25 allows for the "D" bit in the Call Request
and Data packets to request "Delivery Confirmation". When this
option is available and used, RR packets advise successful
receipt by the *remote* DTE, not the local DCE.
--
_______ Jim Breen (jwb@cit5.cit.oz) Department of Robotics &
/o\----\\ \O Digital Technology. Chisholm Inst. of Technology
/RDT\ /|\ \/| -:O____/ PO Box 197 Caulfield East 3145
O-----O _/_\ /\ /\ (p) 03-573 2552 (fax) 572 1298tonyg@retix.retix.COM (Tony Goulding) (09/21/89)
In article <1167@virtech.UUCP> dennis@virtech.UUCP (Dennis P. Bednar) writes: > This is correct. X.25 is specified as a protocol between a DTE > (packet switching host) and a DCE (IMP or interface message > processor a.k.a. packet switching node). While X.25 level > 2 (the lowest protocol layer) has reliability built into it > (checksums, acks, retransmissions, sequenced packets), the > reliablility is only between the host and the IMP. There is no > guarantee of end-to-end reliablity between two hosts: I was under the impression that, depending upon the network configuration, the acknowledge can originate either from the local IMP or the remote IMP. As such, this does not provide end-to-end reliability. But, if the X.25 'D' bit is set to 1, end to end reliability is guaranteed, as the packet ack will then originate not from one of the IMP's, but from the remote DTE. In an OSI stack, network end-to-end reliability is not assumed. So, effectively, the D bit is set to 0. A class 0 transport will provide implicit flow control (sequence numbering), class 2 will provide negotiated flow control (sequencing & credit). Both these classes can therefore detect unreliability (out of sequence packets) and will disconnect. They will not recover. Class 4 transport also provides sequencing and credit info, and will reset and retransmit if it discovers a sequencing problem. However, even class 4 will give up after a while, and so to guarantee end-to-end reliability, a Session layer would be used. Tony.
danny@idacom.UUCP (Danny Wilson) (09/21/89)
In article <1989Sep18.020822.16329@cit5.cit.oz>, jwb@cit5.cit.oz (Jim Breen) writes: : In article <1167@virtech.UUCP>, dennis@virtech.UUCP (Dennis P. Bednar) writes: : [...] : * a level 3 DATA packet and receives a level 3 RR acknowledgement : * packet from the local IMP (on the left side of the above : * diagram), it only means that the local IMP has acked the : * packet, but not necessarily that the remove DTE in the : * right side of the figure has even received it. ..........[etc] : : Full 1984/1988 X.25 allows for the "D" bit in the Call Request : and Data packets to request "Delivery Confirmation". When this : option is available and used, RR packets advise successful : receipt by the *remote* DTE, not the local DCE. Although the spec states that if you use the 'D' bit in a data packet, I have not run into an actual switch yet that supports this functionality. This includes some switches that actually implement the '84 standard. Anyone aware of a switch that implements this function? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta {att, watmath, ubc-cs}!alberta!idacom!danny C A N A D A
karn@jupiter (Phil R. Karn) (09/22/89)
In article <727@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: >Although the spec states that if you use the 'D' bit in a data packet, >I have not run into an actual switch yet that supports this functionality. > >This includes some switches that actually implement the '84 standard. > >Anyone aware of a switch that implements this function? Telenet's network seems to act as though the D-bit were always set. That is, packet-layer RRs are propagated end-to-end. Apparently they do this as more of an ad-hoc congestion-avoidance scheme than out of concern for reliable data transfer. But this works strongly against performance even when there is no danger of congestion, because the default X.25 packet layer window is only 2 128-byte packets, and the extra delay incurred by the end-to-end RRs means that the maximum achievable throughput over a single virtual circuit can be abysmal. This results in hacks like "downward multiplexing", where a datagram-based DTE (e.g., the CSNET IP-on-X.25 gateway) opens multiple virtual circuits to the same destination and spreads its datagrams among them. It often takes 4 or 5 parallel virtual circuits to keep a single 9.6kb/s access link busy. The result is unnecessarily complicated code, lots of dropped packets and thrashing of virtual circuit connections because of table limits, and a high rate of out-of-order packet delivery. When I wrote my TCP, I found the best way to *really* test it under fire was to connect across a CSNET IP-on-X.25 gateway. Face it, X.25 is a disaster for anything other than remote slow speed terminal multiplexing. It is not suitable for serious computer networking. Phil
jwb@cit5.cit.oz (Jim Breen) (09/22/89)
In article <727@idacom.UUCP>, danny@idacom.UUCP (Danny Wilson) writes: > > Although the spec states that if you use the 'D' bit in a data packet, > I have not run into an actual switch yet that supports this functionality. > > This includes some switches that actually implement the '84 standard. > > Anyone aware of a switch that implements this function? > The public X.25 PSN in Australia (AUSTPAC) supports "D" bit now (It didn't for its first couple of years). AUSTPAC went live in 1983 with DPS25 switches from SESA in France. It is just about to start a rebuild with new switches from Northern Telecom (in Canada!), presumably with D bit still supported. -- _______ Jim Breen (jwb@cit5.cit.oz) Department of Robotics & /o\----\\ \O Digital Technology. Chisholm Inst. of Technology /RDT\ /|\ \/| -:O____/ PO Box 197 Caulfield East 3145 O-----O _/_\ /\ /\ (p) 03-573 2552 (fax) 572 1298
larry@pdn.paradyne.com (Larry Swift) (09/22/89)
In article <17683@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes:
Telenet's network seems to act as though the D-bit were always set. That
...
the end-to-end RRs means that the maximum achievable throughput over a
single virtual circuit can be abysmal. This results in hacks like
"downward multiplexing", where a datagram-based DTE (e.g., the CSNET
IP-on-X.25 gateway) opens multiple virtual circuits to the same
destination and spreads its datagrams among them. It often takes 4 or 5
parallel virtual circuits to keep a single 9.6kb/s access link busy.
...
Face it, X.25 is a disaster for anything other than remote slow speed
terminal multiplexing. It is not suitable for serious computer
networking.
Seems like a quantum leap from an obvious hack to a blanket condemnation
of X.25. It would be easy (and obvious?) for a private X.25 network to
open the window size to a more optimal value based on number of hops.
Larry Swift larry@pdn.paradyne.com
AT&T Paradyne, LG-132 Phone: (813) 530-8605
8545 - 126th Avenue, North
Largo, FL, 34649-2826 She's old and she's creaky, but she holds!haas%basset.utah.edu@cs.utah.edu (Walt Haas) (09/23/89)
In article <1167@virtech.UUCP> dennis@virtech.UUCP (Dennis P. Bednar) writes: > While X.25 level 2 (the lowest protocol layer) has reliability built into it >...reliablility is only between the host and the IMP[sic] correct > There is no guarantee of end-to-end reliablity between two hosts >... >In other words, when the local DTE on the left sends >a level 3 DATA packet and receives a level 3 RR acknowledgement >packet from the local IMP (on the left side of the above >diagram), it only means that the local IMP has acked the >packet, but not necessarily that the remove DTE in the >right side of the figure has even received it. Incorrect - if you set the D bit in the data packet, the RR has end-to-end signifcance. Paragraph 4.3.3 of CCITT Recommendation X.25: 4.3.3 Delivery confirmation bit The setting of the Delivery Confirmation bit (D bit) is used to indicate whether or not the DTE wises to receive an end-to-en acknowledgement of delivery, for data it is transmitting, by means of the packet receive sequence number P(R). -- Walt
karn@ka9q.bellcore.com (Phil Karn) (09/23/89)
>Seems like a quantum leap from an obvious hack to a blanket condemnation >of X.25. It would be easy (and obvious?) for a private X.25 network to >open the window size to a more optimal value based on number of hops. The specific situation I was describing (IP on Telenet) involved a public data network, and Telenet didn't support any way to negotiate the window size to a more optimum value. You have a point with regard to private X.25 networks. But you beg the question, because private networks have the option of using something other than X.25. Why should I use X.25 in my private computer network in the first place? ("Because it's an *International* *Standard*!" doesn't carry much weight in my book). If you need to build a private network that can support certain hosts or applications that require an X.25 network service, you should do it without inflicting X.25 on the rest of us that don't want or need it. For example, Cisco's new software release supports the creation of a virtual X.25 network on top of an IP network. Phil
adam@castle.ed.ac.uk (Adam Hamilton) (09/25/89)
In article <17683@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: > >Face it, X.25 is a disaster for anything other than remote slow speed >terminal multiplexing. It is not suitable for serious computer >networking. > The UK nearest equivalent to the ARPANET is JANET which links the UK academic sites. It is an X25 network. We run login (X29), FTP, Mail, the News and JTMP (Job Transfer and Management) over it. It works just fine. Throughput through a switch will be several hundred megabytes a day. If two hosts have 64K bits-per-sec links I can easily manage 32K bps throughput in the data transfer phase of FTP. How serious do I have to get?
terry@uts.amdahl.com (Lewis T. Flynn) (09/26/89)
In article <17701@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >>Seems like a quantum leap from an obvious hack to a blanket condemnation >>of X.25. It would be easy (and obvious?) for a private X.25 network to >>open the window size to a more optimal value based on number of hops. > >The specific situation I was describing (IP on Telenet) involved a public >data network, and Telenet didn't support any way to negotiate the window >size to a more optimum value. If my memory is correct (it's been three years), X.25 requires the implementation to allow window sizes from 1 to 7 with other sizes up to 127 optional. If Telenet doesn't allow other than 2 (the required default), then it doesn't meet the standard. Terry <usual disclaimer>
jimm@haddock.ima.isc.com (Jim McGrath) (09/27/89)
The 1976 version of Telenet provided private facilities for packet/window size specification. Some other PDNs translated the Throughput Class facility to window, and sometimes packet, size. I think I have notes on all the old hacks at home if anyone is interrested. Jim
karn@ka9q.bellcore.com (Phil Karn) (09/27/89)
>Throughput through a [JANET] switch will be several hundred megabytes a day. That's only a few tens of kilobits per second. The US Internet is now largely based on T-1 (1.536 megabit/sec) links, and the routers in at least our portion of the Internet (JvNCNet) have no trouble keeping their links full if enough traffic is offered. DS-3 (43 megabit) links are already being talked about, and the router manufacturers say they'll be able to handle them in a year or so. Can JANET's X.25 switches run at multi-megabit throughputs? >If two hosts have 64K bits-per-sec links I can easily manage 32K bps >throughput in the data transfer phase of FTP. That's a good illustration of the main problem with X.25. Even with the relatively small default 576 byte MSS, a FTP transfer with TCP/IP achieves about 93% of the link speed in actual user data, assuming a full duplex path and a sufficiently large window size to keep the pipe full. If there's a performance problem in the Internet right now, it's that the TCP window sizes on most hosts are now too small to fully utilize the new T1 links. But TCP is a transport protocol, so it resides in the end systems where it's much easier for me to change than if it were buried inside the network. Phil
howard@cos.com (Howard C. Berkowitz) (09/30/89)
In article <1989Sep18.020822.16329@cit5.cit.oz>, jwb@cit5.cit.oz (Jim Breen) writes: > In article <1167@virtech.UUCP>, dennis@virtech.UUCP (Dennis P. Bednar) writes: > * This is correct. X.25 is specified as a protocol between a DTE > * (packet switching host) and a DCE (IMP or interface message > * processor a.k.a. packet switching node). While X.25 level > * 2 (the lowest protocol layer) has reliability built into it > * (checksums, acks, retransmissions, sequenced packets), the > * reliablility is only between the host and the IMP. There is no > * guarantee of end-to-end reliablity between two hosts: > * > * (local) (local) (remote) (remote) > * DTE DCE DCE DTE > * host <---> IMP <---> IMP <----> host > * > * In other words, when the local DTE on the left sends > * a level 3 DATA packet and receives a level 3 RR acknowledgement > * packet from the local IMP (on the left side of the above > * diagram), it only means that the local IMP has acked the > * packet, but not necessarily that the remove DTE in the > * right side of the figure has even received it. ..........[etc] > > Full 1984/1988 X.25 allows for the "D" bit in the Call Request > and Data packets to request "Delivery Confirmation". When this > option is available and used, RR packets advise successful > receipt by the *remote* DTE, not the local DCE. > -- While the base standards of CCITT (i.e., Recommendation X.25) and ISO (ISO 8208) do define the D bit, this is largely for historical reasons. Very few (none to my knowledge) public data network implementations support end-to-end significance of the Delivery Conformation bit. Specifically for the OSI context, the NIST (formerly NBS) OSI Implementors' Workshop agreements prohibit negotiation to obtain end-to-end significance, as does the European SPAG Guide to the Use of Standards. In the OSI context, there are two main ways by which X.25 is used. The first, probably more familiar, is to provide the Connection-Oriented Network Service (CONS), the X.25 realization of which is defined in ISO 8878. CONS will be expected to have OSI Transport above it. The second is one way to provide the Connectionless Network Service (CLNS); it uses X.25 to provide a technology-specific interface to a packet-switching network, but the service interface shown to Transport is connectionless, based on the OSI Internet Protocol (ISO 8473). OSI Transport is explicitly defined as an end-to-end protocol; it has different classes with increasingly powerful error detection and control. Class 4, the most powerful, is comparable to TCP in functionality. Lower classes (only classes 0, 2, and 4 are supported by European and North American OSI functional standards, as well as in draft International Standardized Profiles). The different classes provide different quality of service over different service-providing networks. Briefly, the network designer decides on what undetected connection and undetected bit error level is economically justified, and uses a transport class which will provided that over the real service-providing network. Class 0 is intended for relatively reliable (e.g., typical X.25) "Class A" networks, where the service network does bit error connection and signals disconnections to the service user. Class 2 is intended for "Class B" networks which reliably notify the user of disconnects, but do not do error correction. Class B networks are typified by X.21 circuit switching, and probably ISDN "B-nailed" circuit switched access. Class C networks are considered unreliable (e.g., LANs, and require Class 4 transport. A connectionless transport service (COTS) comparable to UDP is in a draft standard. So, while the D-bit is provided in the base standards, no one really uses it. -- howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [W] (703) 998-5017 [H] DISCLAIMER: Opinions expressed are not necessarily those of the Corporation for Open Systems, its members, or any standards body.
howard@cos.com (Howard C. Berkowitz) (09/30/89)
In article <6576@pdn.paradyne.com>, larry@pdn.paradyne.com (Larry Swift) writes: > In article <17683@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: > Telenet's network seems to act as though the D-bit were always set. That > ... > the end-to-end RRs means that the maximum achievable throughput over a > single virtual circuit can be abysmal. This results in hacks like > "downward multiplexing", where a datagram-based DTE (e.g., the CSNET > IP-on-X.25 gateway) opens multiple virtual circuits to the same > destination and spreads its datagrams among them. It often takes 4 or 5 > parallel virtual circuits to keep a single 9.6kb/s access link busy. > ... > Face it, X.25 is a disaster for anything other than remote slow speed > terminal multiplexing. It is not suitable for serious computer > networking. I agree that X.25 does not always have optimal performance characteristics, although it can sometimes be tuned (see below). Something to bear in mind, however, is that X.25 is the only interface available on a reasonably worldwide basis. European ministries of posts and telegraphs have historically been EXTREMELY reluctant to permit (and they can enforce this) use of non-X.25 networks. Currently planned data interfaces to ISDN are oriented to X.25, although one can set up a 64KBPS connection between pairs of points and run anything over them, the PTT willing. So, while X.25 is not ideal, it will probably be only thing usable worldwide for 10-20 years or so. There may be faster and more effective protocols on Son of Internet (T3 or whatever), but vendors will need to look at these as adjuncts to X.25, simply because these improved protocols will not be available everywhere. Just as much as we need new effective protocols, we need to know how to wrest the best possible performance from X.25. > > Seems like a quantum leap from an obvious hack to a blanket condemnation > of X.25. It would be easy (and obvious?) for a private X.25 network to > open the window size to a more optimal value based on number of hops. 1984 X.25 provides a mechanism for negotiating a non-default (default normally being 2) window size; whether a given network supports nonstandard window sizes is a good question when selecting among network vendors. Using modulo 8 sequence numbering, windows up to 7 can be supported, and up to 127 with modulo 128. Other performance parameters, such as maximum data packet size and a throughput objective, can be negotiated. Implementation of these negotiation features is network dependent. -- howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [W] (703) 998-5017 [H] DISCLAIMER: Opinions expressed are not necessarily those of the Corporation for Open Systems, its members, or any standards body.
larry@pdn.paradyne.com (Larry Swift) (10/02/89)
In article <22877@cos.com> howard@cos.com (Howard C. Berkowitz) writes: >The second is one way to provide the Connectionless Network Service >(CLNS); it uses X.25 to provide a technology-specific interface >to a packet-switching network, but the service interface shown to Transport >is connectionless, based on the OSI Internet Protocol (ISO 8473). This description seems to be implying a reason for this interface, but if so, it escapes me. Can you provide some background as to why network designers might want a CNLS interface over an inherently connection-oriented network layer? If the Layer 3 path traversed multiple subnets with an unreliable segment such as X.25-Ethernet-X.25, is the CNLS interface to Layer 4 no less viable than the CONS? Is it simply easier to use? What else? Larry Swift larry@pdn.paradyne.com AT&T Paradyne, LG-132 Phone: (813) 530-8605 8545 - 126th Avenue, North Largo, FL, 34649-2826 She's old and she's creaky, but she holds!
howard@cos.com (Howard C. Berkowitz) (10/10/89)
In article <6624@pdn.paradyne.com>, larry@pdn.paradyne.com (Larry Swift) writes: > In article <22877@cos.com> howard@cos.com (Howard C. Berkowitz) writes: > >The second is one way to provide the Connectionless Network Service > >(CLNS); it uses X.25 to provide a technology-specific interface > >to a packet-switching network, but the service interface shown to Transport > >is connectionless, based on the OSI Internet Protocol (ISO 8473). > > This description seems to be implying a reason for this interface, > but if so, it escapes me. Can you provide some background as to why > network designers might want a CNLS interface over an inherently > connection-oriented network layer? If the Layer 3 path traversed > multiple subnets with an unreliable segment such as X.25-Ethernet-X.25, > is the CNLS interface to Layer 4 no less viable than the CONS? Is it > simply easier to use? What else? One of the uglier problems in current OSI is that Transport (at least connection-oriented transport) does have expectations about the characteristics of the underlying Network Service. Transport over CNLS cannot directly interoperate with transport over CONS. A number of factors are involved, including whether Transport depends on the lower layer (i.e., network) to tell it whether a connection has broken. There are a variety of solutions to this problem, including transport relays. The definitive solution is still evolving. Note that X.25 over LANs is used in Europe as a circumvention to this difficulty. -- howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [W] (703) 998-5017 [H] DISCLAIMER: Opinions expressed are not necessarily those of the Corporation for Open Systems, its members, or any standards body.
jimm@haddock.ima.isc.com (Jim McGrath) (10/11/89)
In article <23189@cos.com> howard@cos.com (Howard C. Berkowitz) writes: >There are a variety of solutions to this problem, including transport >relays. The definitive solution is still evolving. Note that >X.25 over LANs is used in Europe as a circumvention to this >difficulty. >-- Prime Computer runs X.25 over their proprietary Ringnet LAN, as well as providing X.25 service over WANs. Jim
cliff@violet.berkeley.edu (Cliff Frost) (10/11/89)
In article <23189@cos.com> howard@cos.com (Howard C. Berkowitz) writes: > >One of the uglier problems in current OSI is that Transport (at least >connection-oriented transport) does have expectations about the >characteristics of the underlying Network Service. Transport >over CNLS cannot directly interoperate with transport over CONS. >A number of factors are involved, including whether Transport depends >on the lower layer (i.e., network) to tell it whether a connection >has broken. > Caveat: I knew next to nothing about OSI before InterOp this year, and I don't know much (if any) more now. I'd like to learn, which is the why of this note. Why not just run TP4 everywhere? It could run over X.25 just as well as over connectionless, couldn't it? That would at least reduce the number of complexities in OSI by a large amount. What do TP0-TP3 give you that TP4 doesn't? (This question was raised by someone at InterOp and no one even tried to answer it--does this mean it was an extremely stupid question or an extremely good one?) The only argument I've heard is that TP4 is too expensive a transport protocol for some cases--but Van Jacobson's work pretty soundly squashes that reasoning. What key point(s) am I missing? (I mean, technically--not politically.) >There are a variety of solutions to this problem, including transport >relays. The definitive solution is still evolving. Note that >X.25 over LANs is used in Europe as a circumvention to this >difficulty. Transport relays mean you lose all hope of end-to-end checksumming. After several years of maintaining a production network this is too grim for me to contemplate. X.25 over LANs? Somehow this sounds like a "worst of both worlds" scenario. I thought X.25 and virtual circuits were supposed to buy you things like congestion control and "guaranteed" throughput. How do they do that over ethernets? Thanks very much, Cliff Frost Central Computing Services University of California, Berkeley <cliff@berkeley.edu>
howard@cos.com (Howard C. Berkowitz) (10/11/89)
In article <14858@haddock.ima.isc.com>, jimm@haddock.ima.isc.com (Jim McGrath) writes: > In article <23189@cos.com> howard@cos.com (Howard C. Berkowitz) writes: > >There are a variety of solutions to this problem, including transport > >relays. The definitive solution is still evolving. Note that > >X.25 over LANs is used in Europe as a circumvention to this > >difficulty. > >-- > Prime Computer runs X.25 over their proprietary Ringnet LAN, as well > as providing X.25 service over WANs. An interesting historical note here is that the first generation of Telenet switches used Prime minicomputers rather than especially designed packet switches. Prime was closely involved, therefore, in the initial U.S. public network implementation of X.25 (1976). Prime machines are still used for Telenet network control centers (a specific set of functions as opposed to a place or organization), and, in large systems, use X.25 over the Prime LAN for interprocessor communications. -- howard@cos.com OR {uunet, decuac, sun!sundc, hadron, hqda-ai}!cos!howard (703) 883-2812 [W] (703) 998-5017 [H] DISCLAIMER: Opinions expressed are not necessarily those of the Corporation for Open Systems, its members, or any standards body.
karn@ka9q.bellcore.com (Phil Karn) (10/16/89)
>Why not just run TP4 everywhere? It could run over X.25 just as well >as over connectionless, couldn't it? That would at least reduce the >number of complexities in OSI by a large amount. What do TP0-TP3 >give you that TP4 doesn't? (This question was raised by someone at >InterOp and no one even tried to answer it--does this mean it was >an extremely stupid question or an extremely good one?) That's actually an extremely good question. The answer has to do with the *real* motivation behind OSI -- namely, the *thwarting* of true, interoperable internetworking by the European PTTs in order to protect their X.25 network monopolies. There can be no other explanation for the existence of five separate and incompatible "transport classes" in OSI, all providing the same connection-oriented service to the next higher layer. It is often said that the US must "migrate" to OSI "so we can talk to the Europeans." But the sad truth is that the Europeans will use TP0 above X.25 while the US will use TP4 above CLNS. The result will be two (or more) incompatible islands, even though both will be nominally "OSI compliant". OSI is the biggest bill of goods that has ever been sold to the US government (with the possible exception of SDI). Anyone in Europe (or elsewhere) who is seriously interested in true multivendor internetworking is already running TCP/IP, and its use in Europe is growing rapidly despite the best efforts of the local governments to stamp it out. It would have been far better had the TP-4 and CLNS protocols never been added to OSI; then those interested in serious internetworking would never have been fooled by the OSI siren song into the upcoming Chinese Fire Drill that will be the TCP-to-OSI "migration". The European PTTs must be laughing their heads off about now. Phil
prc@erbe.se (Robert Claeson) (10/17/89)
In article <17899@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes: >It is often said that the US must "migrate" to OSI "so we can >talk to the Europeans." But the sad truth is that the Europeans will use >TP0 above X.25 while the US will use TP4 above CLNS. The result will be >two (or more) incompatible islands, even though both will be nominally >"OSI compliant". Well, US GOSIP 1.0 prefers running TP4/CLNS everywhere, even over WAN's while US GOSIP 2.0 includes TP0/CONS, TP2/CONS, TP4/CONS (for a WAN system connected to a LAN system) and even TP4/CLNS/CONS (for LAN-WAN-LAN configurations), just like the Swedish SOSIP 1.0 does. Both of the also specifies the TELNET VT profile and are looking at the Transparent, Scrolling and Forms profiles. UK GOSIP 3.0, on the other hand, prefers running TP0/CONS even on LAN's and mandates the Forms VT profile. Just to show that all European Government ISO profile's aren't created equal, even though this admittedly doesn't have much to do with the European PTT's. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
larry@pdn.paradyne.com (Larry Swift) (10/18/89)
>>Why not just run TP4 everywhere? It could run over X.25 just as well >That's actually an extremely good question. The answer has to do with >the *real* motivation behind OSI -- namely, the *thwarting* of true, >interoperable internetworking by the European PTTs in order to protect >their X.25 network monopolies. There can be no other explanation for the This rabid, OSI-bashing statement aside, the answer to the question is that TP4 over X.25 is a relatively poor performer for the resources consumed (ie, protocol overhead in both layers for ACKing data units). TP2 over X.25 is at least more efficient. I agree that OSI isn't perfect, and Layer 4 in particular is unlovely, but to ascribe the *real* motivation behind OSI as above is pure nonsense. Larry Swift larry@pdn.paradyne.com AT&T Paradyne, LG-132 Phone: (813) 530-8605 8545 - 126th Avenue, North Largo, FL, 34649-2826 She's old and she's creaky, but she holds!
karn@jupiter..bellcore.com (Phil R. Karn) (10/19/89)
>This rabid, OSI-bashing statement aside, the answer to the question >is that TP4 over X.25 is a relatively poor performer for the resources >consumed (ie, protocol overhead in both layers for ACKing data units). >TP2 over X.25 is at least more efficient. In other words, my original statement is still true, namely that ISO doesn't really consider universal interoperability to be particularly important despite all their hype to the contrary. Or at least it's not as important to them as what Michael Padlipsky once called their "bit saving fetish" regarding header overhead. I think the ARPA Internet approach, with interoperability of paramount concern, has proven by its tremendous popularity that people consider the convenience of a single, universal, transparent Internetwork service to be well worth whatever extra header overhead it requires. Personally, I think the header overhead issue is a red herring. Bulk data transfers can always reduce header overhead to an arbitrarily small value by just increasing the data packet size. In fact I once computed that the total overhead of a TCP/IP file transfer using the Internet default MSS of 576 bytes is actually less than an unprotected X.25 transfer using the very common X.25 network default packet size limit of 128 bytes. (Yes, I know you're supposed to be able to increase the X.25 packet sizes, but if header overhead was so vitally important, don't you think they would have made the defaults larger?) Header overhead in TCP/IP is significant only for small, interactive packets over slow and expensive links. But Van Jacobsen's recent point-to-point header compression work (described in the SLIP session at Interop) has shown that you need not sacrifice the universality or the robustness of the TCP/IP approach to attain good performance over slow links. He's got the typical Telnet data packet down to 5 bytes or so. All it took was one smart person working on the problem. Performance across X.25 is an issue only because of the European PTTs' hammerlock on data communications. If they'd privatize and deregulate their markets, and in particular if they'd sell leased lines at reasonable prices to resellers and private network operators so they could build more modern computer networks like we have in the US, I think you'd see the concern disappear. Why else would the US be going for TP4 while Europe goes for TP0? The laws of physics and mathematics are the same on the two continents; the differences are in the laws governing competition in telecommunications. >I agree that OSI isn't perfect, and Layer 4 in particular is unlovely, >but to ascribe the *real* motivation behind OSI as above is pure nonsense. Yeah, I probably violated my own rule of "never attribute to malice that which can be adequately explained by stupidity". But one still wonders, given so many blatantly misleading claims from the OSI camp. I should say here that I'm definitely not "rabidly" opposed to the entire OSI effort. Once in a while, an idea appears in OSI that might actually be worth trying. And if somebody can demonstrate through actual experiment (not a paper study) that a particular OSI service is actually "better" (in some widely agreed sense, be it functionality, performance, or implementability) than an existing Internet service, then I'd agree that we should use it. Heck, I'm a big supporter of the metric system because it's clearly better than what we now use. The problem is that, by and large, this just isn't the case with OSI, especially in the lower and middle layers (transport on down). A forced "transition to OSI" here will yield NO MEANINGFUL ADVANTAGES WHATSOEVER over TCP/IP in terms of performance, interoperability or services. But it WILL be very expensive, disruptive and confusing to an awful lot of people, especially those trusting neophytes who have bought the OSI salesman's pitch hook, line and sinker. Perhaps the best approach is the one being taken by Marshall Rose's ISODE package, which concentrates on the ISO applications while using the existing TCP/IP infrastructure. If there's ANY advantage AT ALL in going to OSI, it'll be in the applications -- although this is far from proven. Nevertheless, they're worth experimenting with, just in case. I can say that an awful lot of excess baggage is going to have to go before the OSI applications could ever become usable standards. But if you're going to tell me I have to "go OSI" and toss out a perfectly good Internet just because the Government says so, and not because of an legitimate reason, then I think I can be excused if I get a little upset. The last time the US Government scrapped a perfectly good existing technology in favor of a heavily hyped universal replacement, we couldn't launch anything into space for over a year. And we're still recovering from THAT fiasco. Phil
cliff@violet.berkeley.edu (Cliff Frost) (10/20/89)
In article <17953@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: > >Performance across X.25 is an issue only because of the European PTTs' >hammerlock on data communications. If they'd privatize and deregulate >their markets, and in particular if they'd sell leased lines at >reasonable prices to resellers and private network operators so they ...etc I'm told by someone in Finland that the Finnish PTT is offering a service that sounds like a leased line. It may still be X.25 based (maybe not) but instead of paying by the packet they pay by the bandwidth reserved regardless of how many packets they send. Apparently this was in response to demand from TCP/IP (who later plan to be TP4/CLNP) internetworkers there. So, at least one European PTT is giving their users a choice. I've been collecting a lot of very helpful and interesting responses to my original question, in a week or so I should be able to post a summary. Thanks, Cliff
jh@tut.fi (Hein{nen Juha) (10/20/89)
In article <1989Oct19.212614.15549@agate.berkeley.edu> cliff@violet.berkeley.edu (Cliff Frost) writes:
I'm told by someone in Finland that the Finnish PTT is offering a
service that sounds like a leased line. It may still be X.25 based
(maybe not) but instead of paying by the packet they pay by the
bandwidth reserved regardless of how many packets they send.
Apparently this was in response to demand from TCP/IP (who later
plan to be TP4/CLNP) internetworkers there. So, at least one
European PTT is giving their users a choice.
The backbone of the Finnish PTT service called DATANET is not based on
X.25 but on point-to-point links directly connecting Cisco routers (so
you don't loose any bandwith). If someone in Finland now wants to
join FUNET (Finnish Research and University Network) and from thereon
to NORDUnet and Internet, they can simply subscribe to DATANET which
has 64Kb line (to be soon upgraded to 2Mb) to our Cisco.
So our State PTT very much wants to respond to customer needs and they
don't seem to give damm to CCITT/CEPT politics. The reason for this
is simple: they don't have monopoly on data services. In most EC
countries this is not the case and, as a result, we are widnessing
forced pushing of X.25/TP0 technology for both WANs and LANs.
--
-- Juha Heinanen, Tampere Univ. of Technology, Finland
jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)