Re: [tcpm] TCP zero window timeout?

Ted Faber <faber@ISI.EDU> Wed, 30 August 2006 16:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIShn-0005oj-2E; Wed, 30 Aug 2006 12:14:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIShl-0005oe-8l for tcpm@ietf.org; Wed, 30 Aug 2006 12:14:17 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISB6-0005Ex-RO for tcpm@ietf.org; Wed, 30 Aug 2006 11:40:32 -0400
Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIRvi-00021S-8J for tcpm@ietf.org; Wed, 30 Aug 2006 11:24:40 -0400
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.6) with ESMTP id k7UFMBGi011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 08:22:11 -0700 (PDT)
Received: (from faber@localhost) by hut.isi.edu (8.13.8/8.13.8/Submit) id k7UFMB04017186; Wed, 30 Aug 2006 08:22:11 -0700 (PDT) (envelope-from faber)
Date: Wed, 30 Aug 2006 08:22:11 -0700
From: Ted Faber <faber@ISI.EDU>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: [tcpm] TCP zero window timeout?
Message-ID: <20060830152210.GI15769@hut.isi.edu>
References: <20060829165756.GB89836@hut.isi.edu> <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com>
Mime-Version: 1.0
In-Reply-To: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com>
User-Agent: Mutt/1.4.2.2i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: -2.6 (--)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>, tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, Fernando Gont <fernando@gont.com.ar>
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="===============0810722732=="
Errors-To: tcpm-bounces@ietf.org

On Tue, Aug 29, 2006 at 11:13:14AM -0700, MURALI BASHYAM wrote:
> > As an aside, RFC1122 says pretty unambiguously that
> > both holding a zero
> > window and probing it regularly are intentionally
> > supported.
> 
> It does, and i dont understand the rationale of
> probing *infinitely* as long as the client is
> acknowledging the probe with a zero window. It's
> possible that the authors did not have the potential
> of a DOS attack when they created this mechanism. In
> the scenario that i am talking abt these probes were
> sometimes running for hours together and such
> connections were ultimately starving out other
> legitimate users traffic.

The probes come a long time apart after a little while - exponential
backoff.

If you're running out of buffer space, abort the connections.

> > 
> > > This does not take into account the fact that
> > > connections are persisting and probing for peer's
> > zero
> > > window which is fundamental to the discussion.
> > 
> > The resource your proxy is running out of is CPU to
> > do window probes???
> > If so, that's very surprising.  If not, can you tell
> > me what your
> > concern is?
> > 
> 
> The resources in question are connections and buffers.
> Here we are talking potentially huge numbers of them
> (100000 connections and even if each connection holds
> 1 buffer, that's a lot of buffer memory). A mechanism
> to reclaim these resources  would have to take into
> account the duration of the persist state of the
> connections, it can't be done blindly.

But that state is easily kept track of by the application.  Close the
ones that are using the most space and have made the least progress.
Even if your implementation doesnt give you access to the full state a
conformant TCP stack does (RFC 793 p. 49) gathering that information is
pretty easy.  I don't know what your environment is, but most have some
way to get this or infer it.

Once the app is short of space and knows which connections it likes
least, it can abort them and reclaim all the resources.

> > Without getting too philosophical, the designers of
> > TCP did explicitly
> > support connections that lock out transmission via a
> > zero window size.
> > 
> 
> I think the crux of the issue here is that this is
> left to the client side application control which
> means open game for hackers.

I agree with your premise, but not your conclusion.

I don't understand why you're against doing this in the app, but I don't
think I understand your whole problem either.  I suggest writing a draft
and giving us the full picture.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm