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

Murali Bashyam <> Sun, 05 October 2008 04:48 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 09FF23A68F9; Sat, 4 Oct 2008 21:48:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 614243A68F9 for <>; Sat, 4 Oct 2008 21:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.684
X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X44tiwEKaxem for <>; Sat, 4 Oct 2008 21:48:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3E5F33A68DE for <>; Sat, 4 Oct 2008 21:48:13 -0700 (PDT)
Received: from exchsvr01.ocarina.local ([]) by exchsvr01.ocarina.local ([]) with mapi; Sat, 4 Oct 2008 21:48:45 -0700
From: Murali Bashyam <>
To: David Borman <>, Murali Bashyam <>
Date: Sat, 04 Oct 2008 21:48:37 -0700
Thread-Topic: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
Thread-Index: AcklnA2e2MXArg1GSAaMUO85RtQh+AAHXndQ
Message-ID: <EC7B72027914A242B991C029F5F213CF2AB0CCA823@exchsvr01.ocarina.local>
References: <> <> <EC7B72027914A242B991C029F5F213CF2AB0CCA6AA@exchsvr01.ocarina.local> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "Anantha Ramaiah (ananth)" <>, "" <>, Ted Faber <>
Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: David Borman []
> Sent: Friday, October 03, 2008 2:05 PM
> To: Murali Bashyam
> Cc: Ted Faber;; Anantha Ramaiah (ananth); Murali Bashyam
> Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document
> On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote:
> >
> > 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.
> If this is true, it should be clarified.  1122 does not in any way say
> that ABORT does not apply to connections in persist state (probing a
> zero window).
> ...
> >> 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.
> Just to be clear: TCP DOES NOT ABORT THE CONNECTION!  The OS or the
> application can choose to ABORT the connection, but TCP does not make
> this decision.  TCP does have retransmit timers, and it is allowed to
> terminate unresponsive connections, but it does not abort connections
> just because they are in persist state for long periods of time.
> Until you are running out of resources there is no good reason to
> terminate connections in persist state, and when you are running out
> of resources, it is the OS that is deciding whether or not to ABORT
> any TCP connections.

I agree that the retransmit/persist timeout analogy doesn't apply to this situation.
It is ONLY the OS or resource manager or the application that can terminate the connection
In this state.

> >> 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.
> Yes, that is an opinion, but it is wrong.  In no way does 1122 say
> that connections in persist state cannot be ABORTed.  What 1122 does
> say is that a connection being in persist state for a long time is not
> sufficient reason *by itself* to terminate a TCP connection, i.e.,
> don't time it out like you would a connection to a non-responsive host.

Just so that we are all clear, i want to summarize the goals of the draft here once again:

1. Clarify the 1122 ambiguity/stance on the sender behavior in persist state.
2. Document (for informational purpose) the consequence of this behavior leading to
the DoS possibility.
3. Specify that the OS/application can terminate the connection in this state using the 793 ABORT interface.

We are NOT documenting the various memory management considerations/issues surrounding the DoS scenario, that's left to the implementers discretion.

We will change the section that's ambiguous regarding the sentence that goes "TCP itself should not take any action...".

tcpm mailing list