Subject: RE: keep RST data nonstandardized for the future!

From: Bernie Volz <[email-masked]>
Date: Wed, 2 Aug 2000 15:07:09 -0400

When we discussed this today, it was decided to consider an instrumentation
option for TCP. One of the instrumentation values would be a code (or codes)
for the cause of a RST. Implementations are thus still free to do what they
do today (such as placing a text message in the data portion); however, that
is only useful for packet tracing and is not available or useable by an
application. Note that an API interface (for BSD sockets for example) was
not really discussed for the instrumentation option and might be an issue to
consider.

Likely, an option would be sent in a SYN to advertise the ability to support
the instrumentation option. Lack of a reply with a similar option in the
SYN/ACK would mean that the peer does not support the option and hence it
would not be used. (This is similar to how other options, such as SACK,
work.)

Don't flame this approach yet as it is still in the process of being
developed. Also, my brief description above likely has not done it justice.

- Bernie Volz

-----Original Message-----
From: Eric A. Hall [mailto:[email-masked]]
Sent: Wednesday, August 02, 2000 2:13 PM
To: Ian Heavens
Cc: Jerry Toporek; [email-masked]; [email-masked];
[email-masked]
Subject: Re: keep RST data nonstandardized for the future!

> I've actually written 75% of this draft and included Jerry's codes
> that he helpfully sent me three years ago!  Also as far as I am aware
> Mentat is the ONLY TCP stack in wide circulation to use these codes.

ONLY has no relevance to WIDE; it's the ONLY or it's not.

The problem with data in the stream is multi-dimensional. First of all,
the specs let anybody do anything, and I guarantee that somebody is
doing something that won't be appreciated. It is highly likely that
there are at least a few implementations which (1) use some format you
do not, (2) leave binary data as leftovers in the RST, or (3) will do
something else in the future since the spec allows it.

If we are going to standardize on the interpretation of errors, then the
representation should be standardized in such a way that interpretation
is not likely. Reverse-standardizing on legacy representations does not
satisfy that objective. In other words, if we find out that in some
particular scenario there are many stacks which leave binary junk in the
data stream for RST then your spec will be instantly broken.

To wit:

> I followed the FTP/SMTP code / string idea in the draft as Rick
> suggested

That will make legacy Mentat implementations non-compliant, and will
require coding around.

The primary benefit of an RST option is that the representation of the
failure is removed from the datastream, guaranteeing that the only
implementations who do anything with it are the implementations who know
WHAT to do with it explicitly.

A secondary benefit is that TEXT data is not required, but instead there
is room for explicit codes/types in 2 bytes of option data (four bytes
if you include all the option overhead which isn't necessary with
options that are not variable-length).

Trying to do this in the free-form datastream is a bad idea all around,
I believe.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 02 Aug 2000 12:14:28 -0700

> Likely, an option would be sent in a SYN to advertise the ability to
> support the instrumentation option. Lack of a reply with a similar
> option in the SYN/ACK would mean that the peer does not support the
> option and hence it would not be used. (This is similar to how other
> options, such as SACK, work.)

In the case of RST being issued in response to the SYN request, there
would be no successful negotiation.