Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!netwrx1!mindel
From: mindel@netwrx1.UUCP (Joshua L Mindel)
Newsgroups: comp.protocols.iso.dev-environ
Subject: ISODE 6.0 & SunLink X.25,OSI 6.0 on the MILNET
Keywords: ISODE 6.0 MILNET SunLink 6.0
Message-ID: <817@netwrx1.UUCP>
Date: 6 Feb 90 23:22:05 GMT
Organization: NetWorks One Inc., Vienna, VA
Lines: 119


Does anyone have experience with a Sun 3 running the following software suite 
to communicate on the MILNET (or another PDN):

			SunOS 4.0.3
			ISODE FTAM and/or FTAM/FTP Gateway 6.0
			SunLink X.25 6.0
			SunLink OSI 6.0 	?

If yes, I'd like to talk with you about it.

We have two Sun 3s, each attached to the MILNET via 9600 bps X.25 (LAPB) links
to the PSN, running the above software suite. 

We are having reliability problems.  Occasionally, our FTAM session
is aborting after completion of a get or put.  The file transfer seems to
complete, the ftam message stating the number of bytes transferred and the
transfer rate appears, and then after a long delay, ISODE returns with a
message stating that the session was aborted for a "Reason not specified
at Transport Level".

Though on the surface this appears to be an X.25 problem, file transfers
using Sun's mapcp (simplified FTAM program) seem to be very reliable.  The
only pattern that seems to appear is that when it fails, it fails when
when attempting to close out a get or put.

If anyone has had similar experience or (best of all) has a solution, please
contact me.

Following is a list of pertinent X.25 configuration parameters that will
further define our environment:

Retransmission timer		4500 msec
Max delay before ACK		2000 msec
Max idle link timer		18000 msec
Max Frame Size			134 bytes
Max Retries			10
Window Size			7
Default packet size		128
Timeout after sending	RESET REQUEST	180 sec
Timeout after sending	CALL REQUEST	200 sec
Timeout after sending 	RESTART REQUEST	180 sec
Timeout after sending	CLEAR REQUEST	180 sec

Thanks in advance for any insight you can offer.


			Joshua L Mindel
			Senior Analyst
			Networks One
			Usenet: uunet!netwrx1!mindel
			Internet: mindel%netwrx1@uunet.uu.net
		
From mindel Mon Feb  5 02:33 EST 1990
>From mindel  Mon Feb  5 02:33:49 1990
Received: by netwrx1 (4.12/2.4S)
	id AA05466; Mon, 5 Feb 90 02:33:49 est
Message-Id: <9002050733.AA05466@netwrx1>
Subject: ISODE 6.0, SunLink X.25,OSI 6.0, and MILNET
To: comp.protocols.iso.dev-environ
Date: Mon, 5 Feb 90 2:33:47 EST
Cc: graham (Jim Graham), slaski (Robert Slaski), mindel (Joshua L Mindel),
        lavender (Greg Lavender)
X-Mailer: ELM [version 2.2 PL10]
Status: RO


Does anyone have experience with a Sun 3 running the following software suite 
to communicate on the MILNET (or another PDN):

			SunOS 4.0.3
			ISODE FTAM and/or FTAM/FTP Gateway 6.0
			SunLink X.25 6.0
			SunLink OSI 6.0 	?

If yes, I'd like to talk with you about it.

We have two Sun 3s, each attached to the MILNET via 9600 bps X.25 (LAPB) links
to the PSN, running the above software suite. 

We are having reliability problems.  About 25% of the time, our FTAM session
is aborting after completion of a get or put.  The file transfer seems to
complete, the ftam message stating the number of bytes transferred and the
transfer rate appears, and then after a long delay, ISODE returns with a
message stating that the session was aborted for a "Reason not specified
at Transport Level".

Though on the surface this appears to be an X.25 problem, file transfers
using Sun's mapcp (simplified FTAM program) seem to be very reliable.  The
only pattern that seems to appear is that when it fails, it fails when
when attempting to close out a get or put.

If anyone has had similar experience or (best of all) has a solution, please
contact me.

Following is a list of pertinent X.25 configuration parameters that will
further define our environment:

Retransmission timer		4500 msec
Max delay before ACK		2000 msec
Max idle link timer		18000 msec
Max Frame Size			134 bytes
Max Retries			10
Window Size			7
Default packet size		128
Timeout after sending	RESET REQUEST	180 sec
Timeout after sending	CALL REQUEST	200 sec
Timeout after sending 	RESTART REQUEST	180 sec
Timeout after sending	CLEAR REQUEST	180 sec

Thanks in advance for any insight you can offer.


			Joshua L Mindel
			Senior Analyst
			Networks One
			Usenet: uunet!netwrx1!mindel
			Internet: mindel%netwrx1@uunet.uu.net