Sure, excuse me for not being more specific.
There's two specific areas of interest to me
- There's no TIME-WAIT protection after RST. This just needs
documentation as I don't think anyone wants to change the TCP state machine
to fix this. I've been meaning to write this up for submission
as an Informational RFC. I guess once that's done, if there
was any interest in fixing the issue, it could be discussed then
- There is the potential to include an error code with a RST
(RFC 1122 permits data in the RST segment), and the Mentat TCP
implementation has been using this for many years (so we can
be confident that TCP implementations do not do anything nasty
when they receive a RST with data). There's no standard
for such error codes and I wonder if implementors would be
interested in proposing a taxonomy. I know that such an error
code would be very useful in diagnosis. With an API the
application layer could exchange error codes, though probably
someone will point out that there is a better way of doing that..
Additionally issues with RSTs came up in RFC 2525 and every now
and then they crop up (see the two RST-related issues in the RFC).
An awful lot of HTTP connections terminate with a RST (P-HTTP
fixes this but I wonder if other applications will depart from
the norm of graceful termination in both directions). RSTs
used to be considered as rare error conditions but maybe
this is no longer true.
Worth a discussion if anyone out there is interested?
PS as an aside, what mechanism does SCTP have to avoid TIME-WAIT
(a question for Vern)?
On Tue, Aug 01, 2000 at 09:51:59AM -0400, Scott Lawrence wrote:
> I think that it would be helpful if you would be more specific about
> what sort of issues you'd like to discuss.
> I am in Pittsburg, and interested in what the issues might be, but
> that invitation was a bit nebulous - and in any event it would be good
> to get the issues on the list so that they get wider visibility.
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 ian@...