Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document

Somewhat snipped up.

On Fri, Oct 03, 2008 at 12:37:10PM -0700, Murali Bashyam wrote:
> On Fri, Oct 3, 2008 at 11:37 AM, Ted Faber <faber@isi.edu> wrote:
> >
> > In light of that I think that the sentence about "TCP itself SHOULD
> > not[sic] take any action..." is more confusing than the 1122 section.
> > It seems to imply that TCP might react differently to an abort than
> > the single paragraph in 793, and I don't think that's the case.
> 
> 
> What's meant here is that it's okay for the connection to get aborted
> in this state, whatever the mechanism for doing so maybe: TCP can
> abort the connection and inform the application, similar to the
> retransmit/persist timeout mechanisms already in place, or the
> application can choose to abort the connection based policy, or the OS
> can do so based on resource management criteria. We can re-word that
> sentence and paragraph to reflect this.

I disagree with "TCP can abort the connection and inform the
application."  RFC 1122 says that TCP must allow the connection to stay
open.  I believe that TCP closing or aborting such a connection (without
an abort command being issued) violates 1122.  External entities (OS,
resource allocator, applications) can abort the connection, as they can
abort any connection.

The point is that the OS and applications (and other entities in a
system) can both annhilate TCP connections regardless of the state of
those connection to meet their needs.  I believe that's a perfectly
adequate tool for dealing with resource starvation.  Delivering that
message seems a valid WG item.

> 
> >
> >
> > Now, a strictly defined abort command seems to somewhat contradict my
> > earlier comments about allowing implementers some freedom.  This is a
> > spot where the standards body has required a specific tool to be
> > available to applications (and OSes and resource managers): there must
> > be a way to annihilate a TCP connection from outside without regard to
> > its state or anything else.  The standard is silent about how the
> > command is used; that's the flexibility here.
> 
> 
> The abort semantics as specified by 793 are clear, they are not
> specific to a particular state, it's the opinion of the authors that
> 1122 excludes it from being applied in this state.

Can you say that again?  What you typed says both that the abort command
is independent of connection state and that it doesn't work on
connections in a certain state.  That sentence contradicts itself, so
I must be misunderstanding something.

For the record, I believe that when a TCP stack receives an abort
command for a connection in persist state the stack must abort the
connection as per RFC 793, p. 50.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG