Subject: RE: Doubletree RST 'BOF' meeting notes

From: Bernie Volz <[email-masked]>
Date: Thu, 3 Aug 2000 10:03:49 -0400

I was one of the people that suggested that.

However, I believe that the plan might be as follows:
1) The to be created "TCP Instrumentation" option will be used to carry a
RST error code. This would likely be a 8 or 16 bit value (256 codes is
probably more than enough). This code is meant to be available to an
application such that it can issue an appropriate error message or otherwise
react better to the cause of the RST if it wants to.
2) A stack would be free to include any error text it wanted (or other data)
in the TCP data portion of the RST packet. However, as this will not be
standardized, it is also possible that "junk" is there (for example,
application data). The intent of this data would be for debugging purposes
when doing packet traces and not something available to the TCP stack or
application. It would also not be standardized. (Implementators might also
be warned about making sure that the message fits within the maximum segment
size being used by the connection and perhaps not setting the Don't Fragment
bit in the IP header.)

- Bernie

-----Original Message-----
From: Craig Partridge [mailto:[email-masked]]
Sent: Thursday, August 03, 2000 9:21 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Doubletree RST 'BOF' meeting notes

>I don't know if anyone wants to follow up the instrumentation option
issue??
>HP/Mentat/Spider/(Sun?) will complete and submit my RST error codes draft. 

Some of the email suggested the error codes should follow the SMTP/FTP
convention (3 digit numbers where the different digits indicate the
severity of error).  I thought that was a nice idea.  Is that still the
plan?

Thanks!

Craig

---

From: Ian Heavens <[email-masked]>
Date: Thu, 3 Aug 2000 15:24:12 +0100

There's nothing to stop implementors including the RST error code
+ ASCII string in the data part of the RST field, purely as a 
debugging aid:

a) pending standardisation of the TCP Instrumentation Option
b) if the offer of the TCP Instrumentation Option must be disabled
   (presumably a TCP-Instrumentation-Option-permitted option analagous
    to the SACK-permitted option in SACK?) because it crashes the receiver.
c) if the receiver refuses the TCP Instrumentation Option

a)  and b) mean that the current usefulness provided by the Mentat stack
is maintained (and extended to other implementations if they so wish
- though only those that don't allow the application to send data with
a RST?).  

From what I hear, (b) could be true for quite a long time, at least
with some implementations.

ian

-- 
Ian Heavens, Spider Software Ltd., http://www.spider.com/
8 John's Place, Leith, Edinburgh EH6 7EL. 
Tel +44 131 475 7015 fax. +44 131 475 7001  [email-masked]