Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

MURALI BASHYAM <> Sun, 02 December 2007 21:31 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IywPF-0004it-25; Sun, 02 Dec 2007 16:31:17 -0500
Received: from tcpm by with local (Exim 4.43) id 1IywPE-0004eZ-27 for; Sun, 02 Dec 2007 16:31:16 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IywPD-0004cI-Kk for; Sun, 02 Dec 2007 16:31:15 -0500
Received: from ([]) by with smtp (Exim 4.43) id 1IywPC-0001uJ-VH for; Sun, 02 Dec 2007 16:31:15 -0500
Received: (qmail 32163 invoked by uid 60001); 2 Dec 2007 21:31:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=rDQut2GjtziY6ODLUakOvaVsw0mqF4RfyE82+QODlC21b1tUINZ8ihk0Q4vyj899KFdNrfRGc1mh2xTqt66sQ0jBeC92BpqBDfj9onYIBC/dIlRKNQN9t6C6xZml3UY9xYxoQjG9fZZ5TwSc+/R/G3zyASQD6IKWrS0MWppfm0w=;
X-YMail-OSG: Iw.FsHcVM1mHr31uCHzfJUXyA_.GPH12rMJqtd7wkFY5lLzF4Y8F7rvxm8wDDFmL_0D0R7rU6ZkHREvoIEP25R9tWvnRghbNpVFNp.QYQNXcPeArLGc-
Received: from [] by via HTTP; Sun, 02 Dec 2007 13:31:13 PST
X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157
Date: Sun, 2 Dec 2007 13:31:13 -0800 (PST)
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
To: David Borman <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: TCP Maintenance and Minor Extensions WG <>, Mark Allman <>, Joe Touch <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

----- Original Message ----
> From: David Borman <>
> Cc: TCP Maintenance and Minor Extensions WG <>rg>; Joe Touch <>du>; Mark Allman <>
> Sent: Thursday, November 29, 2007 9:09:29 AM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
> On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
> ...
> > The second aspect is the ability of the application to explicitly  
> > cause the TCP connection
> > to leave the ZWP state at the specified time independent of  
> > available resources. There are
> > applications where having this level of control over the TCP  
> > connection makes sense (web, game servers).
> > But aborting this connection with trigger from TCP or OS or  
> > application is a protocol violation, i don't buy the fact
> > that if the OS does it, it's not a violation, that's what i was  
> > referring to as pure wordplay.
> Fine.  Call it wordplay.  There's nothing wrong with that, because
> you
> *have* to get the words right.  You have to be crisp on the protocol  
> definition.  The implementation can blur the boundaries, but the  
> protocol definition can't.   The aborting of a connection (whether in  
> persist or any other state) when the other side is alive and  
> responding has to be done by the application.  TCP should not be
> doing
> that without direct instructions from the application.  Whether that  
> is done directly by the application by using the existing abort or  
> user timeout interface, or whether a new interface is defined to
> allow
> the application tells the OS to run a timer and abort the connection  
> when the timer goes off, it is still being done under the direction
> of
> the application.
> > A protocol is a contract between the sender and receiver here, and  
> > the contract defines the wire
> > behaviour.
> The TCP protocol is what is defined in RFC 793/1122, and any other  
> RFCs that are applicable.  It is more than just the wire behavior.
> > I care about the wire behaviour of the
> > connection, and if i observe the behaviour of the connection in the  
> > ZWP state prior to this change, i see
> > ACKs and probes exchanged infinitely. With this change (no matter  
> > who does it, OS, app, TCP), i see
> > ACKs and probes being exchanged for some time, followed by a RST  
> > segment to abort the connection.
> >
> > Do you agree that if we do the latter without changing the wording  
> > of RFC1122, it's a protocol
> > violation?
> > My claim all along has been that it is.
> There already exists two mechanisms for the application to abort a  
> connection, directly with the abort interface, or indirectly with the  
> user timeout on the send interface, and you will get the same wire  
> behavior, a connection in persist state gets aborted.
> The only protocol problem here is to have TCP abort a connection in  
> ZWP state without the application having first explicitly asked for  
> that to happen.  And if you need a new interface to provide that  
> functionality, then that will be a change to the TCP protocol.
> The OS freeing up resources when they run out by doing things like  
> aborting connections is not a protocol violation, because it isn't
> making that decision.  Take that to the extreme, and you'd be arguing  
> that the system crashing is a TCP protocol violation, and that's just  
> silly.
> >
> >
> > If we agree that it's a violation, then it's a standards track  
> > nature of draft.
> If it changes TCP, in this case adding a new User/TCP interface, then  
> it should be on the standards track.

I agree with your suggestions, a new User/TCP interface is needed to enable the ZWP timer specificially, 
and  have TCP inform the app to ensure  that we limit the duration of the connection in the ZWP state. 
It's upto the application to enable the timer and take the abort action when the timer expires. But TCP will have to take abort action in the scenario where the application has already closed the connection.

A separate document (informational) can be written to describe how the application can use the new interface, and also discuss the DoS implications of the ZWP state and provide recommendations on a solution and what it needs to accomplish. 

Ted, Mark : What do you think?


>             -David Borman

Never miss a thing.  Make Yahoo your home page.

tcpm mailing list