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

Joe Touch <touch@ISI.EDU> Sun, 02 December 2007 18:33 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 1IytdZ-0000B9-JJ; Sun, 02 Dec 2007 13:33:53 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IytdY-0000Au-Qw for tcpm-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 13:33:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IytdY-00009w-Gf for tcpm@ietf.org; Sun, 02 Dec 2007 13:33:52 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IytdY-0004Ew-0t for tcpm@ietf.org; Sun, 02 Dec 2007 13:33:52 -0500
Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lB2IXCs0011490; Sun, 2 Dec 2007 10:33:13 -0800 (PST)
Message-ID: <4752FA54.3050801@isi.edu>
Date: Sun, 02 Dec 2007 10:32:52 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
References: <825882.78624.qm@web31708.mail.mud.yahoo.com>
In-Reply-To: <825882.78624.qm@web31708.mail.mud.yahoo.com>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: Anantha Ramaiah <ananth@cisco.com>, TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>, David Borman <david.borman@windriver.com>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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="===============1517731987=="
Errors-To: tcpm-bounces@ietf.org


MURALI BASHYAM wrote:
...
>> Applications should have changed long ago. Some definitely need to
>> catch up. There is no way to handle DOS attacks with legacy
>> applications written in a legacy manner.
> 
> I think you missed my point, let me explain. Application here does NOT care
> about reliable delivery of data to the peer after it has closed the connection.
> Hence SO_LINGER is out. Web behaves this way and by any standards it is not a legacy
> application.  

By your metrics, so are any modifications of the TCP API that require
rewriting the app. Web servers have been multithreaded for a long time -
and even reuse threads to avoid thread creation (see Apache).

> Can you explain why an application should keep a connection or socket state around 
> after it has closed the connection AND it does not care about reliable delivery of data to the peer?

If it doesn't care about reliable delivery, why did it use TCP? Why
didn't it ABORT the connection instead of CLOSE?

Your example is inconsistent; if you care about reliable delivery AND
you care about resource attacks you stick around. If you don't, you are
susceptible to DOS attacks.

> If it did, they would be using SO_LINGER already, hence my comment about not making
> socket layer usage recommendations to the app. Even in this scenario, it's important
> that *****TCP**** does not run out of connection and buffer resources, however.

TCP doesn't have resources. The OS does.

> I think the key point this issue illustrates is that it is TCP's resources which are under attack
> here, and not the application's. I think this distinction has emerged in this email thread 
> a while back, and i don't think there is any disagreement abt it.

There have been a few of us who believe that the resources under attack
are the OS's, not TCP, and then there are the authors - who believe
otherwise.

> In most modern systems, these are managed as distinct resources and TCP resources (read
> connection memory and buffer memory) can get starved with app resources available in plenty.
> If application resources are under attack, that's application responsibility, of course.

An app IS under attack when its connections are attacked.

Joe

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