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

On Fri, Oct 3, 2008 at 11:37 AM, Ted Faber <faber@isi.edu> wrote:

> I don't mean to be answering from John, but your comments interested me.
>
> On Thu, Oct 02, 2008 at 05:13:50PM -0700, Murali Bashyam wrote:
> >
> > > From: John Heffner [mailto:johnwheffner@gmail.com]
> > > I have reservations about moving forward with this draft as a wg
> > > document.  While the information is technically correct, it is overly
> > > specific to the point of possibly being misleading rather than
> > > clarifying.  An operating system may terminate a tcp connection at any
> > > time, not just when the connection is in the persist state.  Further,
> > > I would actually argue that terminating a connection *because* it's in
> > > the persist state is a bad idea and should be discouraged.  (The
> > > reason for termination should be for its use of resources, not TCP's
> > > state.)
> >
> > No implementation today (the well-known ones BSD, Windows and Linux)
> > terminates the TCP connection in that persist state as long as ACKs
> > are being reliably received from the peer. Those three implementations
> > are not doing what you are saying they should be doing, and if it's
> > crystal clear from the standard that they should be doing so, why
> > aren't they?
>
> Your comment is a little ambiguous.  John says that he believes that
> persist state is not necessarily a good marker for aborting connections
> when resources are scarce.  To take him to task because implementations
> are not using it as a marker - because the implementers agreed with
> his position - is a little unfair, IMHO.

My intent was that even where TCP implementations have a scheme for
dropping connections in the event
of resource exhaustion (such as the Linux one does), they have excluded
connections in this state.
The point i am trying to convey is that the 1122 portion has (mis)guided
them in that direction.

>
> On the WG item:
>
> As a bigger picture issue, I find it helpful to remember that
> protocol standards, like 1122, are primarily interoperation documents.
> As such, they tend to focus on what protocol implementers must do to
> talk with one another successfully, not to nail down all possible
> choices.
>
> Once we start offering advice (or stronger) to developers, we're leaving
> the interoperability domain.  We, as a standards body, have to assume
> that implementers know their application and their environment better
> than we do, and that they can and will make appropriate decisions if we
> give them the room to do so.
>
> Where a standard has unnecessarily tied the hands of implementers, that
> standard should be changed, IMHO.  I am also sympathetic to clarifying
> the standards body's intent where poor language has obscured it.  I
> don't see that kind of confusion in the text the authors are addressing
> (that is RFC 1122 Section 4.2.2.17), but reasonable people can disagree
> on such things.
>
> As such, taking on this work item - clarifying 1122 4.2.2.17 - doesn't
> excite me, but I don't oppose it.
>
> The draft should, IMHO, point out that 1122 has nothing to say about
> resource management.  Designers and implementers are free to be as
> clever or foolish as they'd like.

I agree, the primary intention of this draft is not to restrict or present
any resource management schemes, it's to clarify 1122.
In addition,  we are trying to highlight the need for resource management in
this scenario because it leads upto a DoS potential.

>
>
> End of thoughts on the WG item.
>
> As for the draft itself, I'm concerned that it seems to be advocating a
> particular resource management position more strongly than simply
> pointing out that RFC1122 should not affect resource allocation
> decisions.  I also see some misplaced standards language that is
> somewhat confusing.  I'm looking at this paragraph in Section 2:
>
>
>        An extensive discussion took place recently about this issue on
>        the TCPM WG mailing list [TCPM].  The general opinion seemed to
>        be that terminating a TCP connection in persist condition does
>        not violate RFC 1122.  In particular the operating system, a
>        resource manager, or an application can instruct TCP to abort a
>        connection in the persist condition.  TCP itself SHOULD not take
>        any action and continue to keep the connection open as mandated
>        by RFC 1122 unless otherwise instructed to do so.  The exact
>        mechanism by which the instruction to abort the connection is
>        conveyed to TCP is an implementation decision and falls beyond
>        the scope of the current memo.
>
> There's no instruction going on, and one doesn't request an abort.
> Abort is a command in the TCP interface (defined in RFC 793, p. 50) that
> destroys a TCP connection.  Abort works in any state.  Anything with
> access to the TCP interface, including the OS, a resource manager, or an
> application, can call it.  A TCP abort is "the exact mechanism by which
> the instruction to abort the connection is conveyed to TCP", and the
> only reason that it's outside the scope of this document is that it's
> defined in 793.
>

>
> 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.

>
>
> 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.

Murali

>
>
> --
> Ted Faber
> http://www.isi.edu/~faber <http://www.isi.edu/%7Efaber>           PGP:
> http://www.isi.edu/~faber/pubkeys.asc<http://www.isi.edu/%7Efaber/pubkeys.asc>
> Unexpected attachment on this mail? See
> http://www.isi.edu/~faber/FAQ.html#SIG<http://www.isi.edu/%7Efaber/FAQ.html#SIG>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>

-- 
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL  --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************
------------------------------ CONFIDENTIAL  --------------------