Re: [tcpm] Is this a problem?

Mark Allman <mallman@icir.org> Mon, 19 November 2007 20:49 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDZ8-0007OF-V9; Mon, 19 Nov 2007 15:49:58 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuDZ7-0007O7-14 for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:49:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDZ6-0007Nz-MM for tcpm@ietf.org; Mon, 19 Nov 2007 15:49:56 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDZ6-00029U-5e for tcpm@ietf.org; Mon, 19 Nov 2007 15:49:56 -0500
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lAJKniZe021990; Mon, 19 Nov 2007 12:49:45 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id F0DF2121C9E6; Mon, 19 Nov 2007 15:49:39 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CF8602F64A4; Mon, 19 Nov 2007 15:49:19 -0500 (EST)
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] Is this a problem?
In-Reply-To: <25299.86272.qm@web31701.mail.mud.yahoo.com>
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: <20071119204919.CF8602F64A4@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0894758832=="
Errors-To: tcpm-bounces@ietf.org

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

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?

allman



_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm