RFC 1323 implementation

[David Borman <[e-mail]>]

Hi,

I've not had any responses to my request for vendor implementations
of RFC 1323, needed for advancing RFC 1323 in the standards process.
So, 1) I've dredged up the list of implementations from July, 1993,
and attached it to the end of this message, and 2) I've added
"[e-mail]" to the Cc: list, hopefully to find
more vendors that have RFC 1323 implemented.  Please send me updates,
I'm sure there are many.

To make things easier, here is an implementation checklist, with
some specific items of interest.  (Additions to this checklist
are welcome.)

	      _  Section 2.2
	  1. |_|   Window Scale Option
	  2. |_|   Only send in SYN/ACK if received in SYN
	  3. |_|   Window Scale size based on receive buffer size

	      _  Section 2.3
	  4. |_|   Shift values > 14 are logged and treated as 14.

	      _  Section 3.2
	  5. |_|   Timestamps Option
	  6. |_|   Only send in SYN/ACK if received in SYN
	  7. |_|   RTT calculations based on Timestamps

	      _  Section 3.4
	 *8. |_|   Update TS.Recent if:
	             SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent

	      _  Section 4.x
	  9. |_|   PAWS
	 10. |_|   "invalidate" TS.Recent if idle > 24 days.
 
	      _  Appendix A:
	*11. |_|   TCP Maxseg option: MSS = MTU - fixed IP/TCP header
	*12. |_|   On output: adjust TCP data length for TCP options
	*13. |_|              adjust TCP data length for IP options

	      _  Appendix C:
	*14. |_|   Disable Karn algorithm w/RTTM

* New/changed items from RFC 1323.


I'll start the ball rolling by adding:

	Vendor: Berkeley Software Design, Inc.
	Product: BSD/OS
	    Version: 4.0
	    Checklist items: 1-14

	    Version: 3.0+patches/3.1
	    Checklist items: 1-12, 14

	    Version: 2.1 & earlier
	    Checklist items: 1-7, 9-12, 14

	Contact: David Borman, [e-mail]

So, please send me your updates.  I'd rather not depend on
an implementation list that is 5 years old.

		-David Borman, [e-mail]

> From [e-mail] Tue Jul 27 13:54:53 1993
> Received: by hemlock.cray.com
> 	id AA08715; 4.1/CRI-5.6; Tue, 27 Jul 93 13:54:56 CDT
> Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
> 	id AA08711; 4.1/CRI-5.6; Tue, 27 Jul 93 13:54:53 CDT
> Received: from frenzy.cray.com by cray.com (4.1/CRI-MX 2.19)
> 	id AA15875; Tue, 27 Jul 93 13:54:51 CDT
> Received: by frenzy.cray.com
> 	id AA05161; 4.1/CRI-5.6; Tue, 27 Jul 93 13:55:45 CDT
> Date: Tue, 27 Jul 93 13:55:45 CDT
> From: [e-mail] (David A. Borman)
> Message-Id: <[e-mail]>
> To: [e-mail]
> Subject: 1323 implementations
> Status: R
> 
> 
> I had an action item from the TCPLW WG meeting in Amsterdam to update
> the list of implementations of the TCP Extensions in RFC 1323.
> Attached is what I have currently, based on the survey that I did
> last December.  If your implementation is not here, please send me
> the relevent information.  If you have updated information on your
> implementation, please send me that information also.  Thanks.
> 
> 			-David Borman, [e-mail]
> 
> ----------
> TCP extensions implementations as of 12/18/92
> 
> Cray Research, Inc
> 
> 	Product: Unicos
> 		Window Scale
> 		Timestamps w/ RTT caluculations (7.0 & later)
> 		PAWS (7.0 and later)
> 		Obsolete Echo and Echo Reply (6.0 & 6.1)
> 
> 	Status: Supported Product
> 
> 	Availability:
> 		Mods available for UNICOS 6.0
> 		Unicos 6.1, 7.0, 7.C
> 
> 	Tested with:
> 		Van Jacobson's code and
> 		many others (see below)
> 
> 	Caveats/Problems:
> 		The 6.0 and 6.1 versions do not support Timestamps,
> 		RTT calculations or PAWS.  They use the obsoleted
> 		Echo and Echo Reply options defined in RFC 1072.
> 
> 		The 7.0 and 7.C versions will send both a Timestamp
> 		and an Echo option in SYN packets.  SYN/ACK packets
> 		will contain either a Timestamp or an Echo, but not
> 		both, depending on what was received in the SYN packet.
> 
> 		Support for the Echo/Echo Reply options will go away
> 		in a future release.
> 
> 		The window scale must be set with an explicit
> 		setsockopt() call, and the use of Timestamps is
> 		tied to the Window Scale option.
> 
> 		If a Window Scale is received in a SYN packet, and
> 		the application hasn't specified otherwise, the
> 		Window Scale is automatically turned around in the
> 		SYN/ACK with the same value.
> 
> 		6.1 has no applications (other than nettest) that
> 		take advantage of expanded windows.
> 
> 		Ftp and ftpd are the only additional applications that
> 		have been enhanced in 7.0 and 7.C to use expanded windows.
> 
> 	Contact: David Borman, [e-mail]
> 
> Interlink Computer Sciences
> 
> 	Product: SNSTCP/access 1.0.1
> 		Window Scale
> 		Timestamps
> 		PAWS
> 
> 	Status: Supported Product
> 
> 	Availability:
> 		PTF MP10497 or PTF MP10498 for 1.1
> 
> 	Tested with: Cray UNICOS
> 
> 	Caveats/Problems:
> 		The code is enabled for port 21 and other ports if they
> 		specify > 64k of buffer space.  Some implementations do
> 		not like this option and fail.  We provide a patch to
> 		turn off this option for all cases.
> 
> 
> 	Contact: Fred Bohle, [e-mail]  (301)-317-6600
> 
> 
> Silicon Graphics, Inc
> 
> 	Product: a future release of IRIX
> 		Window Scale
> 		Timestamps w/ RTT calculations
> 		PAWS
> 
> 	Status: Supported Product
> 
> 	Availability:
> 		"Real Soon Now" (probably spring '93)
> 
> 	Tested with: Cray UNICOS
> 
> 	Caveats/Problems:
> 		Time-stamps are tied to window scaling and window scaling
> 		options will only be used on connections when a send or
> 		receive buffer is explicitely set to >64K.  All other
> 		connections will not use any of the options.
> 
> 		Old style (RFC 1072) echo/echo-reply options will be
> 		ignored.  Only the RFC 1323 combined time-stamp/reply
> 		option is supported.
> 
> 
> 	Contact: Thomas Skibo, [e-mail]
> 
> 
> University of Illinois
> 
> 	Product: Patch to 4.3BSD Net-2 release
> 		Window Scale
> 		Timestamps w/ RTT calculations
> 		PAWS
> 		
> 	Status: Experimental/research/prototype
> 
> 	Availability:
> 		Anonymous ftp from uxc.cso.uiuc.edu:/pub/tcplw.shar.Z
> 
> 	Tested with: Cray UNICOS
> 
> 	Caveats/Problems:
> 		Protocol control blocks are held in mbuf clusters.  This
> 		is very inefficient.  Should probably use kmem_alloc() to
> 		allocate pcbs.
> 
> 		There are problems with handling of options when a socket
> 		in TIME_WAIT gets a new connection request (i.e. the other
> 		side is using SOREUSEADDR).  This can cause the window
> 		scaling options to be ignored in those cases.
> 
> 		FINs aren't taken into account when deciding to update
> 		TS.recent (for the echo reply).  A fix for this is mentioned
> 		in the README file with the patch.
> 
> 		The PAWS check shouldn't drop segments when ts_recent is
> 		zero (i.e. invalid).
> 
> 
> 	Contact: Thomas Skibo, [e-mail]
> 
> 
> Sandia National Laboratories
> 
> 	Contact: Doug Brown, [e-mail]  [phone]
> 
> 	Product: Patch to SunOS 4.1.1, 4.1.2
> 		Window Scale
> 		Timestamps w/ RTT calculations
> 		PAWS
> 
> 	Status: Experimental/research/prototype
> 
> 	Availability:
> 		Contact [e-mail] for availability
> 
> 	Caveats/Problems:
>                 For window sizes above approx 160K bytes, the throughput
> 		drops off noticably.  I suspect some kind of memory
> 		management problems in SunOS, but don't know for sure.
> 
> 	Tested with: Cray UNICOS 6.0 (Window Scaling only)
> 
> 
> Information Sciences Institute (ISI)
> 
> 	Contact: Bob Braden & Liming Wei, [e-mail] & [e-mail]
> 
> 	Product: Patch to Sun OS 4.1
> 
> 		Window Scale
> 		Timestamps w/ RTT calculations
> 		PAWS
> 
> 	Status:
> 		Contact [e-mail] or [e-mail]
> 
> 
> Sun Microsystems Computer Corporations
> 
> 	Contact: Jim Fiori, [e-mail]
> 
> 	Product: SunOS 4.1.X
> 		Window Scale
> 		Timestamps w/ RTT calculations
> 		PAWS
> 
> 	Status: Product, available for purchase
> 
> 	Availability:
> 		This is available as a Sun Consulting Special. These are
> 		software specials that are purchased on an "as-is" basis.
> 		For more information contact your Sun sales rep. The name
> 		of the product is CONSULT-TCPLFN.
> 
> 	Caveats/Problems:
> 		The timestamps/PAWS must be turned on per application
> 		via setsockopt calls. The large windows can
> 		be turned on per application via setsockopt calls.
> 		There are new options for both. In addition, the
> 		default send and receive space (kernel variables) can
> 		be set to use the large windows.
> 
> 
>