Re: [tcpm] TCP zero window timeout?

MURALI BASHYAM <murali_bashyam@yahoo.com> Sat, 26 August 2006 23:05 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH7Dr-0004PU-Cl; Sat, 26 Aug 2006 19:05:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH7Dq-0004PP-3a for tcpm@ietf.org; Sat, 26 Aug 2006 19:05:50 -0400
Received: from web31713.mail.mud.yahoo.com ([68.142.201.193]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GH7Do-0007wO-MZ for tcpm@ietf.org; Sat, 26 Aug 2006 19:05:50 -0400
Received: (qmail 41462 invoked by uid 60001); 26 Aug 2006 23:05:46 -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=dOH4XiFPYfn6cu+TtEGiQTVSjnYjmeG6pr/I+xfI9u0sjFsMFrE9we0fh68EAPayGlIGmQXk0JiP3hDFl7buauR2j1WKnyFrxAHonYfmgtInthsHctWBIuBrtA5phTCKqW+RCGefShfnTCDZiR7r/XCYgwuOYY4OjE+v1XN3p4g= ;
Message-ID: <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com>
Received: from [24.6.24.35] by web31713.mail.mud.yahoo.com via HTTP; Sat, 26 Aug 2006 16:05:45 PDT
Date: Sat, 26 Aug 2006 16:05:45 -0700
From: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: Re: [tcpm] TCP zero window timeout?
To: Fernando Gont <fernando@gont.com.ar>, Mahesh Jethanandani <mahesh@cisco.com>, "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>
In-Reply-To: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.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>
Errors-To: tcpm-bounces@ietf.org

Fernando

I collaborated with mahesh on this, so let me try
making the case for it a little better.

The problem was found on a TCP proxy, which does not
have any applicaton awareness. In fact application
awareness is not a goal in that environment. Hence the
TCP level solution.

Having said that, i'd say this timeout is in the same
spirit as the upper bound on the retransmit mechanism
of TCP. TCP could indefinitely retransmit and have the
application timeout too, correct? The problem is that
TCP has a persist state which can potentially exist
infinitely long  and which lends itself to abuse by a
malicious peer. Just based purely on this
consideration, don't you think TCP should have a
mechanism that reduces the impact of this problem by
either limiting the number of probes (a la retransmit
timeout) or the duration. And the application can turn
it on per connection via a socket option and set a
value which makes sense for that application, so there
is per application per connection control anyway.

Murali

--- Fernando Gont <fernando@gont.com.ar> wrote:

> At 21:00 25/08/2006, Mahesh Jethanandani wrote:
> 
> >The situation I was referring to is a little
> different and applies 
> >to persist timer. In our situation the client stops
> reading data. 
> >These clients are machines out in the Internet and
> as such the 
> >server has no control over their behavior. So while
> there is 
> >unacknowledged data, it is not that the client is
> not acking any 
> >data. It is responding to the probe but that it
> continuously 
> >advertises a window of zero.  There is currently to
> my knowledge no 
> >timeout for this state for the server. This can
> manifest itself as a 
> >DOS situation if there are several such connections
> where the server 
> >is forced to hold data.
> 
> I'd argue that this should be handled by an
> application-level timer.
> 
> The problem with the scenario you point out is that
> there will always 
> be one more way to do the same thing.
> 
> If we're talking about connections wasting
> resources, there are many 
> protocols (POP3, SMTP) in which after the initial
> greeting by the 
> server, the client is supposed to go ahead. In all
> those cases, the 
> client could just sit there. And only an
> application-layer timeout 
> would help you.
> 
> I'm not sure how many servers implement this type of
> 
> application-layer timer. But there are some (Apache)
> that I have 
> checked, and do.
> 
> Nevertheless, I'm interested in the behaviour you
> described. Is it 
> supposed to be malicious activity?
> 
> Kindest regards,
> 
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE
> A9EF D076 FFF1
> 
> 
> 
> 
> > _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm
> 


__________________________________________________
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