Re: [tcpm] TCP zero window timeout?

MURALI BASHYAM <murali_bashyam@yahoo.com> Mon, 28 August 2006 22:59 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHq57-00044N-E3; Mon, 28 Aug 2006 18:59:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHq56-00044I-GM for tcpm@ietf.org; Mon, 28 Aug 2006 18:59:48 -0400
Received: from web31704.mail.mud.yahoo.com ([68.142.201.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHq54-0002Hv-4q for tcpm@ietf.org; Mon, 28 Aug 2006 18:59:48 -0400
Received: (qmail 74383 invoked by uid 60001); 28 Aug 2006 22:59:43 -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=x01qcYe2J7O+3+l8FI9q4zFgrCgJU9HR34ODLAlLTs5DenGWC9bXveg7tw5AQBpXYitbLoCsELllg3BFOvEuK/+GlKnpmSAX0C8f+PekvO98Uj/cSaRVCnFfa/k2L93BQFS8ZFcmnFphdSPd9O/8laqXtctmVRAPfsAIb1Dm1y0= ;
Message-ID: <20060828225943.74381.qmail@web31704.mail.mud.yahoo.com>
Received: from [24.6.24.35] by web31704.mail.mud.yahoo.com via HTTP; Mon, 28 Aug 2006 15:59:43 PDT
Date: Mon, 28 Aug 2006 15:59:43 -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: <20060828173654.GB1252@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: 31247fb3be228bb596db9127becad0bc
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 Sat, Aug 26, 2006 at 04:05:45PM -0700, MURALI
> BASHYAM wrote:
> > 
> > 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.
> 
> (As just a participant)
> 
> 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.

> 
> If a proxy is running out of memory and it has
> connections that are
> largely unused, it should close them.  The proxy is
> at the exact right
> spot to keep track of the connections and their
> usage.  It can tell
> which connections are wasting its resources and it
> knows what it
> considers bad behavior of a connection.  When proxy
> resources get
> scarce, close the connections that are behaving the
> worst - have been
> holding the same proxy resources a long time, for
> example.
> 

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.

> None of that requires application-awareness or TCP's
> complicity.

> 
> And even if it did, TCP enables many applications. 
> To a first
> approximation, increasing TCP's complexity increases
> its fragility.
> Changes to TCP should benefit more than one
> application before they're
> standardized, IMHO.

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.  

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