From owner-freebsd-net Sat May 12 13:57:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from mr200.netcologne.de (mr200.netcologne.de [194.8.194.109]) by hub.freebsd.org (Postfix) with ESMTP id 3C3FE37B423 for ; Sat, 12 May 2001 13:57:08 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from husten.security.at12.de (dial-213-168-73-206.netcologne.de [213.168.73.206]) by mr200.netcologne.de (Mirapoint) with ESMTP id AFK23433; Sat, 12 May 2001 22:57:05 +0200 (CEST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by husten.security.at12.de (8.11.3/8.11.3) with ESMTP id f4CKuvj36941; Sat, 12 May 2001 22:56:57 +0200 (CEST) (envelope-from pherman@frenchfries.net) Date: Sat, 12 May 2001 22:56:57 +0200 (CEST) From: Paul Herman To: jayanth Cc: , Subject: Re: t/tcp behaviour has changed in -current and -stable In-Reply-To: <20010510150047.F45897@yahoo-inc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 10 May 2001, jayanth wrote: > I would like to back out the DELAY_ACK macro changes for now. The > ttcp code behavior has changed because of the addition of the > DELAY_ACK macro. > > The macro is forcing the ttcp code to send an immediate SYN, ACK > for an initial ttcp segment which has the SYN/FIN/PSH flag set. > Instead the SYN,ACK should be delayed such that next segment > should be SYN/FIN/PSH from the server side. I'm hesitant to comment, because I don't really have a patch :-) but I'll give it a whirl anyway. Thing is, delack is still broken. It just isn't nearly as broken now as it was before the patch. I'm pretty sure what you are seeing now, worked before only because of the brokenness. The way to go here is to fix this problem. Besides, if you back out the latest delack change, ttcp will be affected by the old delack problems anyway. I don't have a testbed for ttcp, so I'm flying blind, but how about where you wrote: > if (DELAY_ACK(tp) && (tp->t_flags & TF_NEEDSYN)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > At this point the DELAY_ACK macro returns false because there is a > callout_pending(). Hence the TF_ACKNOW will be set. If the new ttcp SYN,ACKs *always* get delayed, having something like: if ( (DELAY_ACK(tp) || this_is_a_ttcp_connection) && (tp->t_flags & TF_NEEDSYN)) - or - if ( tcp_delack_enabled && (!callout_pending(...) || this_is_a_ttcp_connection) && (tp->t_flags & TF_NEEDSYN)) ...depending on what The Right Thing is when tcp_delack_enabled = 0. I don't know ttcp, so of course "this_is_a_ttcp_connection" should be replaced with the corresponding boolean. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message