Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!karn From: karn@thumper.bellcore.com (Phil R. Karn) Newsgroups: comp.protocols.tcp-ip Subject: Re: Linking LAN's via Public X.25 Summary: Other IP-on-X.25 gateways Message-ID: <1112@thumper.bellcore.com> Date: 31 May 88 20:41:37 GMT References: <13652@comp.vuw.ac.nz> <8805282211.AA02054@sluggo.sun.com> Organization: Bell Communications Research, Inc Lines: 64 While we have not used Sun's Sunlink-X25 product, we used the CSNET X25NET software on a VAX and a GTE Telenet X.25 link for some time. Then we upgraded our Internet membership from Steerage Class to First Class by junking X25 and getting a direct HDH connection to an ARPANET PSN. So I think I can make a few general comments from our experiences in running IP over X.25. Yes, it works. But the fact that it does reflects more on the flexibility and robustness of TCP/IP than on any inherent suitability of X.25 for serious computer networking (as opposed to remote slow speed terminal multiplexing, which is what X.25 was designed for and actually does reasonably well). An IP-on-X.25 gateway is a complex beast, mainly because of X.25's many gratuitous complexities. The most obvious is the need to manage connections. Interfaces usually support only a limited number of them. Worse, carriers may decide to charge you for keeping them open even if they're idle. (Fortunately, Telenet doesn't do this. I guess they're satisfied with the $1500 you pay them every month just to have a 9600 bps host access line to their network. This is exclusive of usage sensitive packet charges, more about them later). The usual strategy here is to keep your list of open connections sorted in order of time of last use, so you can close the least recently used connection should you need to open another one. Timers can also be used to close idle connections. Other problems include inherent performance bottlenecks imposed by the carrier's own interpretation of the X.25 protocol. For example, Telenet acts as though the "D-bit" (delivery confirmation bit) in each packet is set. This means that their packet-layer acknowledgements are on an end-to-end basis. Unfortunately, the packet size is limited to 128 bytes, and the packet layer window is only 2 packets. This means you can't send more than 256 bytes on any single virtual circuit per network round trip time. This can severely limit throughput; in our experience we could seldom use more than 1/4 of the bandwidth of our 9600 bps access line with any one virtual circuit. Since almost all of our IP traffic was to one destination (relay.cs.net) this would have been a serious performance bottleneck except for a feature in the gateway code that opened multiple, parallel X.25 virtual circuits to the same destination and dealt outgoing packets to them in round-robin fashion. Tannenbaum calls this "downward multiplexing"; I call it a "kludge". (By the way, this feature comes in very handy when implementing TCP. There's no other Internet path that gives you such a chance to test your packet resequencing code!). But wait, there's more! Not only is an X.25 gateway inordinately complex, but running it can be very expensive. Telenet, as do all X.25 carriers that I'm aware of, charges for each packet sent. There is a nighttime discount, but the figures are still quite high. If you examine the tariffs, you will find that shipping large files over X.25 can be *very* expensive. In fact, it is considerably cheaper to use one of the new 9600 bps dialup modems -- as low as HALF the cost of X.25. Just to give you an idea, the last month before we dumped it in favor of our ARPANET connection, our X.25 path to the Internet through Telenet and relay.cs.net cost us $10,000. And we did NOT run routing packets over the path. Even a leased line to Cambridge would have been considerably cheaper. Based on my own experiences with IP over X.25, one must wonder what they were smoking down at the Pentagon when the DoD decided to specify X.25 as the standard interface to the DDN. Phil