RE: [tcpm] TCP zero window timeout?

"Caitlin Bestler" <caitlinb@broadcom.com> Tue, 29 August 2006 18:34 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8Pr-0000wj-OJ; Tue, 29 Aug 2006 14:34:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI8Pq-0000we-Ji for tcpm@ietf.org; Tue, 29 Aug 2006 14:34:26 -0400
Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI8Pn-0000bD-Rm for tcpm@ietf.org; Tue, 29 Aug 2006 14:34:26 -0400
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Tue, 29 Aug 2006 11:34:09 -0700
X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A4EE42AF; Tue, 29 Aug 2006 11:34:09 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 806B12AE; Tue, 29 Aug 2006 11:34:09 -0700 (PDT)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EDY57405; Tue, 29 Aug 2006 11:33:57 -0700 (PDT)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E09C020501; Tue, 29 Aug 2006 11:33:56 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] TCP zero window timeout?
Date: Tue, 29 Aug 2006 11:33:56 -0700
Message-ID: <54AD0F12E08D1541B826BE97C98F99F189EDC5@NT-SJCA-0751.brcm.ad.broadcom.com>
In-Reply-To: <20060829181314.50826.qmail@web31715.mail.mud.yahoo.com>
Thread-Topic: [tcpm] TCP zero window timeout?
Thread-Index: AcbLlx1pmkkXC2DtTGaQ5ZYc3Z0XjgAAdXLQ
From: Caitlin Bestler <caitlinb@broadcom.com>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>, Ted Faber <faber@ISI.EDU>
X-TMWD-Spam-Summary: TS=20060829183411; SEV=2.0.2; DFV=A2006082906; IFV=2.0.4,4.0-8; RPD=4.00.0004; ENG=IBF; RPDID=303030312E30413031303230332E34344634383736312E303033442D412D; CAT=NONE; CON=NONE
X-MMS-Spam-Filter-ID: A2006082906_4.00.0004_4.0-8
X-WSS-ID: 68EA572B22G2957656-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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

MURALI BASHYAM wrote:
 
>> 
> 
> 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

I think it is a given that a server application can terminate
the connection to any client if the behaviour of that client
means that the server no longer wishes to maintain the connection.

I am not aware of any RFC that would impair the ability of
the server application to interact with the local TCP stack
to achieve these results.

Is there a specific RFC requirement that you believe impairs
creation of local interfaces to achieve the results you desire?
In general, if the application layer has the right to do something
it has the right to delegate that authority to a lower layer on
the local stack and doing so will contradict the wire protocol.




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