Re: [tcpm] New I-D

Mark Allman <mallman@icir.org> Tue, 20 February 2007 18:11 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZSF-0006qQ-Oc; Tue, 20 Feb 2007 13:11:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZSE-0006oo-63 for tcpm@ietf.org; Tue, 20 Feb 2007 13:11:06 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJZSA-0001TH-P5 for tcpm@ietf.org; Tue, 20 Feb 2007 13:11:06 -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 l1KIAoKp019480; Tue, 20 Feb 2007 10:10:51 -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 5658D7F0A87; Tue, 20 Feb 2007 13:10:45 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9EAFC181B80; Tue, 20 Feb 2007 13:10:23 -0500 (EST)
To: weddy@grc.nasa.gov
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] New I-D
In-Reply-To: <20070213185552.GB7252@grc.nasa.gov>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Cocaine
MIME-Version: 1.0
Date: Tue, 20 Feb 2007 13:10:23 -0500
Message-Id: <20070220181023.9EAFC181B80@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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="===============1324962680=="
Errors-To: tcpm-bounces@ietf.org

Regarding:
  http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt

Wes:
> [...] but it looks to me like this is more of an OS mechanism to
> manage resources rather than a protocol-based mechanism.  Is this
> correct? 

I'm with Wes here.

I just took a spin through the draft and am left with three thoughts ...

  + You say apps don't have a good role to play even after citing apps
    that 'pause' as the culprit.  I can't make these things agree in my
    head.  Even in the absence of TCP-specific information it seems that
    these apps could time themselves out if no progress is being made
    (i.e. data getting exchanged).

    (Further, things like HTTP sends after which the app goes away and
    then getting wedged into persist don't worry me much.  That sounds
    like a once in a blue moon sort of situation to me.)

  + This seems fundamentally like an operating system resource issue to
    me and not something for a networking standards body.  OSes deal
    with all sorts of resource contention issues without standards.  Why
    does this problem need to be solved the same way by each OS?

  + In particular, I think you have solved the problem wrong.  Don't get
    me wrong ... maybe it is perfectly OK for your purposes and it is
    fine with me if you want to use it.  However, I would want something
    a little smarter to really avoid the mythical attacks you describe.
    All you did was to cap the length of connections.  So, conceivably a
    periodic attack could still keep all your resources busy.  It seems
    to me that you'd want to use some sort of scheme that actually took
    into account contention and resource exhaustion.  E.g., some sort of
    LRU what-has-been-in-persist longest when you need new resources and
    they are not available sort of culling scheme?  Or, when you have
    exhausted X% of your resources to keep some in reserve.  That might
    be wrong and busted itself (it is quickly off the top of my head),
    but it at least takes into account the resource contention unlike a
    naive timeout.

Just my two bits ...

allman



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