Subject: 1323 implementations
From: [email-masked] (David A. Borman)
To: [email-masked]
Date: Tue, 27 Jul 93 13:55:45 CDT

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, [email-masked]

----------
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, [email-masked]

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, [email-masked]  (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, [email-masked]

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, [email-masked]

Sandia National Laboratories

	Contact: Doug Brown, [email-masked]  (505)845-8699

	Product: Patch to SunOS 4.1.1, 4.1.2
		Window Scale
		Timestamps w/ RTT calculations
		PAWS

	Status: Experimental/research/prototype

	Availability:
		Contact [email-masked] 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, [email-masked] & [email-masked]

	Product: Patch to Sun OS 4.1

		Window Scale
		Timestamps w/ RTT calculations
		PAWS

	Status:
		Contact [email-masked] or [email-masked]

Sun Microsystems Computer Corporations

	Contact: Jim Fiori, [email-masked]

	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.

Date: Wed, 21 Jul 93 12:36:02 -0500
From: [email-masked] (David Borman)
To: [email-masked]
Subject: Re: TCPLW WG minutes
Cc: [email-masked], [email-masked]

Bob,

> I believe I was also given an action item to publish
> draft-ietf-tcplw-extensions-00.txt as an RFC, after adding to it the
> Borman bug that led to the change in the rule for updating TSrecent.

Right you are.  Here's the text that I will add to the minutes:

	o Bob Braden will update draft-ietf-tcplw-extensions-00.txt
	  to include an updated description of which TS to echo to
	  explain the bug as described above, and then it will be
	  published as an informational RFC.

			-David Borman, [email-masked]

Date: Wed, 21 Jul 1993 09:01:46 -0700
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: TCPLW WG minutes
Cc: [email-masked], [email-masked]

  *> 
  *> 
  *> Action Items
  *> ------------
  *> o Bob Braden will update RFC 1323 with the changes that are
  *>   described in draft-ietf-tcplw-extensions-00.txt.  The new
  *>   document will be sent to the mailing list for final review,
  *>   and then sent to the IESG for consideration for advancement
  *>   to Draft status.

I believe I was also given an action item to publish
draft-ietf-tcplw-extensions-00.txt as an RFC, after adding to it the
Borman bug that led to the change in the rule for updating TSrecent.

  *> 
  *> o David Borman will send out the current list of implementations,
  *>   so that people can send in updates.  The updated list will be
  *>   given to the IESG at the same time as the updated version of
  *>   RFC 1323.
  *> 
  *> Mailing list Archives
  *> ---------------------
  *> Archives of the mailing list can be accessed by using telnet
  *> to host berserkly.cray.com (128.162.96.70), port 23000.
  *> 

Date: Wed, 21 Jul 93 10:54:30 CDT
From: [email-masked] (David A. Borman)
To: [email-masked]
Subject: TCPLW WG minutes
Cc: [email-masked], [email-masked]

Attached is the first draft of the minutes of the TCP LW
working group meeting from the Amsterdam IETF meeting.
If anyone has corrections that should be made, please let
me know ASAP, so that I can get the revision done before
the deadline for submitting WG minutes (the end of next week).

If there are no changes, these will be the final version.

		-David Borman, [email-masked]

--------- Cut Here -----------

TCP Large Windows Working Group
-------------------------------
Summary reported by David Borman, WG Chair.

The TCP Large Windows Working Group met on Wednesday, July 14
at the 27th IETF meeting in Amsterdam.  The agenda consisted
of:
	o Review of draft-ietf-tcplw-extensions-00.txt
	o Consideration of advancing RFC 1323 to Draft
	o Status of SACK option?

The document draft-ietf-tcplw-extensions-00.txt is a compilation
of bugs and clarification that need to be made to RFC 1323.  It
was compiled by Bob Braden.  Bob and David Borman led a walk
through of the document, to help explain it and to find out
if any other changes that are needed to RFC 1323 were missed. 

RTTM: Relationship to Karn's Algorithm
--------------------------------------
One of the items that Karn's Algorithm addresses is how to
get valid RTT values in the presence of lost data.  With
current methods, the answer is that whenever data has to
be retransmitted, no valid RTT estimate can be made in that
window.  The reason for this is that when the ACK is received,
it can not be determined whether that ACK came from the
original packet or the retransmitted packet.

With the use of the Timestamps option, this ambiguity
is removed, since the timestamp echoed in the ACK will
always be from the data packet that caused the ACK of new
data to be generated.

The other part of Karn's Algorithm, that of doing
exponential back-off on retransmissions, still needs
to be done.

RTTM: Which TS to Echo
----------------------
(Note: The discussion given during the WG was a bit muddled.
This summary provides the clearer explanation...)

This is the one real bug in RFC 1323.  As stated currently,
the TSval is only copied to TS.Recent when a packet is
received that advances the left edge of the window.  The
change allows the TSval to be copied when the left edge of
the window is advanced, or if the packet is before the left
edge of the window and it has a newer timestamp.

The scenario that this addresses is when a packet is sent,
its ack is lost, and so the packet is then resent.  The
second packet will not advance the left edge of the window,
but will cause a duplicate ack to be generated.  To the
sender, this will be the first ack that is received, so
it will want to use the timestamp in that packet to update
the RTT estimate.  If the TSval is not copied from the
resent packet, the the sender will get an inflated RTT
estimate.

By making this change, with the use of timestamps for
doing RTT measurements it can be guaranteed that in the
worst case at least one RTT measurement can be made per
window.  Without the timestamps option, in many TCP
implementations one RTT estimate per window is the
best case.

Additionally, this change fixes a problem with a
long-lived unidirectional connection.  Since all the
acks will have the same sequence number, they would
never cause TS.Recent to be updated.  With this change,
the string of ack-only packets will cause TS.Recent to
be kept up-to-date, and allow PAWS to work properly.

TCP Options and MSS
-------------------
The discussion of how the TCP MSS option interacts with the
presence of TCP and/or IP options needed some clarification.
Since many TCP implementations us the MSS option to indicate
how large of a packet can be received without fragmentation,
and the MSS does not include the TCP/IP headers, the question
is should it also be adjusted for the length of the options
that will probably be in each packet?

The answer is no, and when sending data the sender should
always assume that the MSS that was received did not account
for the TCP and IP options, so the MSS should be reduced
by the length of the TCP and IP options when determining
how much data can be sent.  The following grid shows why:

                | MSS is adjusted       | MSS is not adjusted
                | to include options    | to include options
----------------+-----------------------+--------------------
Sender adjusts  | packets are too       | packets are the
length for      | short                 | correct length
options         |                       |
----------------+-----------------------+--------------------
Sender doesn't  | packets are the       | packets are too
adjust length   | correct length        | long.
for options     |                       |

The goal is to not send IP datagrams that have to be
fragmented by IP.  Packets sent with the constraints in
the lower right of this grid will cause IP fragmentation.
The only way to ensure that this doesn't happen is for the
data sender to decrease the MSS by the length of the IP
and TCP options.

Modification to TCP Event Processing Rules
------------------------------------------
The draft document contains a new set of rules for how to
process the TCP extensions.  Bob wanted feedback on whether
or not the format was easy to read and understand.  The
general feeling was that it was easy to read and understand.

SACK
----
There was some discussion of the status of the SACK option.
Right now, there is not a lot of visible activity in this
area.  There are some test implementations of the SACK option
as originally defined in RFC-1072.  The plan is once there
is some hard data on how well it works, then a new draft
document will be generated on the SACK option.

Action Items
------------
o Bob Braden will update RFC 1323 with the changes that are
  described in draft-ietf-tcplw-extensions-00.txt.  The new
  document will be sent to the mailing list for final review,
  and then sent to the IESG for consideration for advancement
  to Draft status.

o David Borman will send out the current list of implementations,
  so that people can send in updates.  The updated list will be
  given to the IESG at the same time as the updated version of
  RFC 1323.

Mailing list Archives
---------------------
Archives of the mailing list can be accessed by using telnet
to host berserkly.cray.com (128.162.96.70), port 23000.