[mod.protocols.tcp-ip] Looking for DDN/X.25 to TCP/IP router

JNC@XX.LCS.MIT.EDU.UUCP (01/21/87)

	Much as you (and I) like 1822, I am given to understand that
requests for new connections using 1822 are no longer being accepted,
unless you can come up with a good reason. Progress marches on...

	Noel
-------

gross@MITRE-GATEWAY.ARPA.UUCP (01/21/87)

> My feelings are that for local connections to the IMP (PSN), 
> 1822DH is far superior if you can get an interface from
> ACC for your system.  A straight 1822DH connection will run
> twice as fast as a comparable X.25 connection simply because 
> the 1822 can signal at about 100-200 Kb/s and you can't connect X.25
> to an IMP faster than 64 Kb/s.  
>  
> All the usual disclaimers apply...
> 
> 			Milo "I love 1822" Medin
> 			NASA Ames/ Bendix Aerospace

Milo,

We have been doing some 1822 vs X.25 comparisons lately.  At first we 
thought we found a major X.25 performance problem but it turned out to
be the vendor's driver.  (For a price, I'll tell you who not to buy...)
We repeated our tests on Mike Petry's machine and actually got reasonable
response.  For hosts on the same Imp, 1822 wins, in cases by a large
margin; but for destinations across the net, the difference begins to
smear out.  By 7 hops away, X.25 wins about half the time.  We have
some nifty graphs that we'll show at the next IETF.

Phill

medin@orion.arpa (Milo S. Medin, NASA ARC Code ED) (01/22/87)

I can certainly believe that.  But under certain circumstances, such as
a gateway with many simultaneous VC's open to PSNs across the network,
I think you may run into the 64Kb/s X.25 host access line speed bottleneck,
a bottleneck that you wouldn't hit with 1822.  Granted the PSN's only have
56 Kb/s lines, but the NASA gateway to the DDN (for example) may be pushing 
traffic through multiple modem port lines and might actually be able to use that
added bandwidth.  I'm not saying using X.25 the way DDN is using it in
Standard service is a bad idea, in fact, its certainly more elegant
than ECU's and the like.  And even for hosts connected to a PSN, 
I think it's quite reasonable because you'll generally not have a 
lot of open VC's to other PSN's, and thus won't hit the 64 Kb/s
bottleneck since the X.25 flow control should block you when you
have lots of outstanding data to a given PSN (just like RFNM's). 
What I am saying is that for certain applications, especially gateways
with large numbers of hosts behind them, which are in many cases 
colocated (or in 1822DH range) with the PSN, that 1822 may provide
better performance with a much simpler interface.  1822 is far from
perfect, but it works, and it's been figured out pretty well
over the years.  I think that in a year or two, the X.25 connections
to PSNs will be pretty well figured out and shaken down.  But
the issue of performance in certain cases may still side with
1822.  If you could plug into a PSN with a 112 Kb/s X.25 line, then I don't
think you'd have that problem.  

Has anyone here done any benchmarking with X.25 connections from PSNs to
gateways in a situation where many VC's are open to multiple PSNs
all at once and plenty of data to send through all of them?  You should
be able to monitor the host access line and see if you are pushing
the limits of line utilization.

In addition, I understand from some folks at BBN that PSN 7.0 will
have a better end-to-end protocol that should greatly improve
X.25 performance.

					Thanks,
					  Milo

Mills@LOUIE.UDEL.EDU (01/23/87)

Milo,

Yes, some measurements have been made on gateways running X.25 to many
PSNs: the scatter diagrams I sent around a month or so ago. They raised
the suspicion, later confirmed, that something was amiss in the gateway
or PSN, not just bad protocol. Mike Petry at U Maryland subsequently
found a bug in a 4.3bsd driver, which gave much joy when fixed. Something
is apparently still wrong with the Ultirx driver, which was coded by
ACC for their 5250 interface.

Like you, I have real problems with the current X.25 design parameters
in the PSNs, but experience with HDH and ECUs suggests realistic level-3
parameters (big packet sizes and bigger windows) should result in performance
not worse than either HDH or ECUs with the same line speeds.

Dave