Re: [tcpm] New I-D

Mark Allman <mallman@icir.org> Wed, 21 February 2007 14:45 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJsio-0002io-Cm; Wed, 21 Feb 2007 09:45:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJsin-0002hy-DA for tcpm@ietf.org; Wed, 21 Feb 2007 09:45:29 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJsim-0008Lz-0B for tcpm@ietf.org; Wed, 21 Feb 2007 09:45:29 -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 l1LEjNwL014475; Wed, 21 Feb 2007 06:45:23 -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 975437FA395; Wed, 21 Feb 2007 09:45:17 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3D3E01827FD; Wed, 21 Feb 2007 09:44:54 -0500 (EST)
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] New I-D
In-Reply-To: <333037.78056.qm@web31715.mail.mud.yahoo.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Cocaine
MIME-Version: 1.0
Date: Wed, 21 Feb 2007 09:44:54 -0500
Message-Id: <20070221144454.3D3E01827FD@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: tcpm@ietf.org, weddy@grc.nasa.gov
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="===============0359913429=="
Errors-To: tcpm-bounces@ietf.org

> It is an implementation to correct a problem caused by
> the protocol's REQUIREMENT for a sender to be in an
> infinite persistence state, thus allowing for abuse by
> a misbehaving receiver side application (or by a lot
> of well-behaved receivers). The draft is outlining a
> solution to the problem (there could be others). The
> idea in the (informational) draft is to highlight to
> the group that requirement of the protocol, its
> consequences and a possible solution.
> 
> Are you suggesting that any requirements of the
> protocol specification that lead to a potential denial
> of service type of scenarios and thus causing internal
> resource contention, and/or any other network issues
> are all to be considered 'implementation' ? Shouldn't
> we look at the requirements of the protocol a little
> more carefully?

Two things:

  + I think it is a big stretch to say this requirement should hold in
    resource constrained situations.  There are a zillion examples where
    a system is supposed to do something, but if it can't do it then it
    can't do it.  And, if a system cannot handle all the established +
    requested connections then something has to give---and, what that is
    ought to be a policy decision.

  + If you do want to read the standard as requiring a TCP to keep this
    connection in the face of everything then you don't need an
    informational because you cannot change a protocol requirement with
    an informational.

> > And, then why is the proposed solution the right
> > one?
> 
> It does solve the problem it sets out to based on a
> "total time allowed to be in persist state" type of
> cap on the duration.
> 
> Are you implying there could be other behaviours from

I am not implying anything.  In my previous note I said that a simple
timeout is a poor solution to the problem because it does not actually
take into account that resources are constrained.

Let me try an example...  Let's say we set this timer to 10 minutes.  A
TCP can stay in persist for 10 minutes.  Two possibilities:

  + The 10 minutes goes by and this is the only connection on the
    machine. 

    Why purge the connection?  The ends are both actively still
    interested and the connection is not causing any problems.

    (Clearly, we could say this is just the machine's policy---that
    connections in persist for 10 minutes get purged.  And, that is fine
    if someone wants to do that.  But, in this case the connection is
    posing no problem and so purging the connection is not addressing a
    problem, just being done due to some sort of house keeping policy.)

  + The 10 minutes goes by and the machine is heavily loaded and has
    turned away dozens or hundreds of connections because of this
    overloaded situation.

    In this case, purging the connection may offer a little relief and
    let other connections come in.  Maybe these will complete and this
    is good.  Or, maybe this is an attack and so the next connection
    will just wedge us for another 10 minutes.

    The point here is that any relief we see from this purging is by
    happenstance and not because we did something to actually address
    the resource constraint problem.  Why did we wait 10 minutes?  Why
    not 9?  Or 11?  If we want to deal with resource issues then we need
    to kick something in when resources are limited.  Kicking some
    connections out at some arbitrary point is just a *hope* that in
    some cases it will help.

What am I missing here?

allman



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