Re: [tcpm] TCP zero window timeout?

MURALI BASHYAM <murali_bashyam@yahoo.com> Tue, 29 August 2006 18:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI85T-00075C-P4; Tue, 29 Aug 2006 14:13:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI85S-000757-DZ for tcpm@ietf.org; Tue, 29 Aug 2006 14:13:22 -0400
Received: from web31715.mail.mud.yahoo.com ([68.142.201.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GI85Q-0003gK-1d for tcpm@ietf.org; Tue, 29 Aug 2006 14:13:22 -0400
Received: (qmail 50828 invoked by uid 60001); 29 Aug 2006 18:13:14 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NNzjzqN6N4vRX+sR/iiLDQIW6rYf3OjjY0ror7LFx1j3tVuuL+iyNSQQMalZ3zmvt9tZYDSSq2iKjJ0+QuaV07ItP/Mx+DcvDdPBHgRw2DSxCM+U1sNBvZSJOuorQkiwzv1cp9ZpmAw1Kf0HWForlLa04+u1F9/Nbttso/zHjg8= ;
Message-ID: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com>
Received: from [24.6.24.35] by web31715.mail.mud.yahoo.com via HTTP; Tue, 29 Aug 2006 11:13:14 PDT
Date: Tue, 29 Aug 2006 11:13:14 -0700 (PDT)
From: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: [tcpm] TCP zero window timeout?
To: Ted Faber <faber@ISI.EDU>
In-Reply-To: <20060829165756.GB89836@hut.isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
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>
Errors-To: tcpm-bounces@ietf.org


--- Ted Faber <faber@ISI.EDU> wrote:

> On Mon, Aug 28, 2006 at 03:59:43PM -0700, MURALI
> BASHYAM wrote:
> > 
> > 
> > --- Ted Faber <faber@ISI.EDU> wrote:
> > > Why get TCP involved here?
> > 
> > Because TCP's requirement to persist indefinitely
> > creates the problem and only TCP is aware of how
> long
> > the peer has been doing zero window offering.
> 
> TCP is completely unaware of how long a client has
> been offering a 0
> receive window.  You'd have to change it to keep
> count of that.  That's
> what you're proposing, correct?  

Correct.

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

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

> Looking at RFC1122 Section 4.2.2.17, it's hard to
> imagine a less CPU-
> intensive way to deal with window probing than the
> exponential backoff
> algorithm suggested there.
> 
> > A TCP sender which is simply trying to probe the
> peer
> > for an indefinitely long amount of time certainly
> > stops helping the application or the system once
> > beyond some amount of time threshold. The
> threshold
> > may be different for different  applications but
> for a
> > given application and a system the threshold
> surely
> > exists.  
> 
> 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.

Murali
> -- 
> 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
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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