RE: [tcpm] TCP zero window timeout?

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrBm-0007O9-9k; Mon, 28 Aug 2006 20:10:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrBk-0007O4-W1 for tcpm@ietf.org; Mon, 28 Aug 2006 20:10:44 -0400
Received: from web31701.mail.mud.yahoo.com ([68.142.201.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GHrBj-0006dv-N9 for tcpm@ietf.org; Mon, 28 Aug 2006 20:10:44 -0400
Received: (qmail 13217 invoked by uid 60001); 29 Aug 2006 00:04:02 -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=MZ22pe1Wlh5MJRSWf3mO+cKKM17DHs38J+mqB4tLzgqLNMw+uQubGjIdxbZvRYCEZBx60BU+zp5U2BYfsoCFxTvHTlRvNk6YoLmkRz5fx3htwlEaU5z/khU1BIo3O8/fpFXZAbadNMoFzagIaWwNt8z+5Xd61wUzLoOkfCWGqsw= ;
Message-ID: <20060829000402.13215.qmail@web31701.mail.mud.yahoo.com>
Received: from [24.6.24.35] by web31701.mail.mud.yahoo.com via HTTP; Mon, 28 Aug 2006 17:04:02 PDT
Date: Mon, 28 Aug 2006 17:04:02 -0700 (PDT)
From: MURALI BASHYAM <murali_bashyam@yahoo.com>
Subject: RE: [tcpm] TCP zero window timeout?
To: Caitlin Bestler <caitlinb@broadcom.com>, Fernando Gont <fernando@gont.com.ar>, Mahesh Jethanandani <mahesh@cisco.com>, "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F189ECE8@NT-SJCA-0751.brcm.ad.broadcom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
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


--- Caitlin Bestler <caitlinb@broadcom.com> wrote:

> MURALI BASHYAM wrote:
> > Fernando
> > 
> > Today there is nothing that prevents a client side
> > application from simply stopping to read the TCP
> receive
> > socket buffer and causing the offered window to go
> down to 0,
> > and thus causing the sender to hold a large send
> queue worth
> > of data and probe forever. If this is done by a
> large number
> > of clients against the same server, u have a
> distributed DOS
> > attack on that server. We have seen this in
> practice.
> > 
> > To answer an earlier question u had raised, the
> application
> > cannot timeout on this connection because it does
> not know
> > when the connection enters and leaves the persist
> state, only
> > TCP knows that. The application can definitely
> decide the
> > timeout value, but TCP needs to implement the
> timer because
> > only it is aware of the state of the peer.
> > 
> 
> True, but why does TCP need any wire protocol
> modifications to
> implement such a timeout locally?

It does not need any wire protocol modifications, but
the intent of this discussion is whether it is
worthwhile to document this at all and if so as a good
practice or  as an informational RFC so that
implementers are aware of the issue and potential
solutions and so on.

Murali
> 
> 


__________________________________________________
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