Re: [tcpm] Is this a problem?

Mark Allman <> Mon, 19 November 2007 20:49 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IuDZ8-0007OF-V9; Mon, 19 Nov 2007 15:49:58 -0500
Received: from tcpm by with local (Exim 4.43) id 1IuDZ7-0007O7-14 for; Mon, 19 Nov 2007 15:49:57 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IuDZ6-0007Nz-MM for; Mon, 19 Nov 2007 15:49:56 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IuDZ6-00029U-5e for; Mon, 19 Nov 2007 15:49:56 -0500
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id lAJKniZe021990; Mon, 19 Nov 2007 12:49:45 -0800
Received: from ( []) by (Postfix) with ESMTP id F0DF2121C9E6; Mon, 19 Nov 2007 15:49:39 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id CF8602F64A4; Mon, 19 Nov 2007 15:49:19 -0500 (EST)
From: Mark Allman <>
Subject: Re: [tcpm] Is this a problem?
In-Reply-To: <>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Who Made Who
MIME-Version: 1.0
Date: Mon, 19 Nov 2007 15:49:19 -0500
Message-Id: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
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: <>, <>
Content-Type: multipart/mixed; boundary="===============0894758832=="

> The problem directly stems from TCP's choice to persist
> indefinitely. It seems a very simple notion of allowing the
> application to be the master here (borrowing Joe's words :-)), and
> providing a ceiling on how long this behaviour will continue. This is
> fully in spirit with how the other TCP timers have evolved and added
> over the years. Now this alone does not address the requirements of a
> co-ordinated distributed DOS attack, but the point here is how long
> the connection should be allowed to (re)try sending data is purely an
> *application* decision i.e it MUST be under application control. It's
> a bad design to have an indefinite retry like this in the transport
> layer without providing an override to the app.  

I don't follow this line of thinking.  Let's see ...

  + I don't know where we have added standard timers to TCP except where
    we have to (e.g., for time-wait or something).  We basically add
    timers when the only things we can count on is the passage of time.

  + It doesn't seem to me a problem that a connection does this persist
    business indefinitely because both ends are consenting.  It isn't
    like one end is silent or going away.

  + The application *is* in control.  The application can close a
    connection whenever it wants to close a connection.  Giving it a way
    to tell TCP when to kill a connection is a distinction without a

I don't think you answered my question in any way.  Why do we have to
standardize this?  It seems to me that if some server wants to implement
a policy that says "a connection can stay in zero window persist for 60
seconds" then great.  Fine.  I don't care.  Might work fine for the use
case of that server.  Might cause problems for its connections.  But, if
that is its policy then wonderful.  Who am I to say that is right or
wrong?  Change the policy and all that still applies.  Seems perfectly
consistent with lots of other things ....

  E.g., who am I to say which SYNs a TCP should accept?  If they are
  from "bad" IPs and I want to drop them on the floor who are you to
  tell me I am wrong?

  E.g., who am I to say how many retransmits you should conduct before
  determining the peer is somehow gone and you give up?

Why does this persist stuff need to be done in a standard fashion?


tcpm mailing list