From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 26 Jan 2001 12:37:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 26 Jan 2001 12:37:52 -0500 Received: from fujitsuI.fujitsu.com ([133.164.253.1]:7871 "EHLO fujitsuI.fujitsu.com") by vger.kernel.org with ESMTP id ; Fri, 26 Jan 2001 12:37:38 -0500 Date: Fri, 26 Jan 2001 09:37:24 -0800 Message-ID: From: Drago Goricanec To: jas88@cam.ac.uk Cc: davem@redhat.com, matti.aarnio@zmailer.org, hpa@zytor.com, linux-kernel@vger.kernel.org Subject: Re: hotmail not dealing with ECN In-Reply-To: In your message of "Fri, 26 Jan 2001 15:08:21 +0000 (GMT)" In-Reply-To: <14961.33191.626833.945221@pizda.ninka.net> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 12) (Channel Islands) (sparc-sun-solaris2.6) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000414(IM141) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Fri, 26 Jan 2001 15:08:21 +0000 (GMT), James Sutherland wrote: > > On Fri, 26 Jan 2001, David S. Miller wrote: > > James Sutherland writes: > > > I was not suggesting ignoring these. OTOH, there is no reason to treat an > > > RST packet as "go away and never ever send traffic to this host again" - > > > i.e. trying another TCP connection, this time with ECN disabled, would be > > > acceptable. > > > > The connection failed, RST means connection reset. RST means all > > state is corrupt and this connection must die. It cannot be > > interpreted in any other way. > > Obviously. The connection is now dead. However, trying to make a new > connection with different settings is perfectly reasonable. Yes for the application, but not for the kernel. The kernel should not make any assumptions about the reason for a RST. Can you just picture if we implement what you are suggesting? Now every single outgoing connection to a non-existant port or for any other reason that returns a RST will have two complete connect cycles. That's bad behavior and will not be tolerated. On top of that, we would have to maintain extra state to decide whether the previous request was a SYN with ECN or some other scenario to avoid reacting to every RST we get. Unnecessary bloat! > > Using it as a metric for ECN enabling is thus unacceptable. > > Why? The connection is dead, but there is nothing to prevent attempting > another connection. I fully support David Miller on this issue. Let Linux lead the path to full adoption of ECN, and we'll all be better for it in the long run. Drago - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/