From owner-freebsd-net@FreeBSD.ORG Tue Feb 10 06:02:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72CB716A4CE; Tue, 10 Feb 2004 06:02:25 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-143.abel.net.uk [193.109.51.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D1A343D2F; Tue, 10 Feb 2004 06:02:24 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id OAA02096; Tue, 10 Feb 2004 14:06:54 GMT From: Richard Wendland Message-Id: <200402101406.OAA02096@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Tue, 10 Feb 2004 14:06:53 +0000 (GMT) In-Reply-To: <4028B68F.41DB11FD@freebsd.org> from "Andre Oppermann" at Feb 10, 2004 11:46:39 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Danny Braniss cc: freebsd-net@freebsd.org Subject: Re: TTCP/RFC1644 problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@wendland.org.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 14:02:25 -0000 > My changes > (tcp hostcache) are in 5.2 for the first time. Before it it's the > legacy code as well. I hope I haven't broken TTCP more than it was > before. > > > and solaris(but i guess they don't do ttcp) and linux (not yet). > > Linux never will. They consider TTCP broken by design. Solaris > I dont know. I'm pretty sure FreeBSD is the only general-purpose OS whose TCP stack implements T/TCP. > Removing it would make maintainance of the tcp code a bit easier. If T/TCP isn't being tested in the release cycle, and it causes problems eg for hostcache, that seems to me a good reason to remove or disable it (remove net.inet.tcp.rfc1644 sysctl), despite the emotional attachment to T/TCP. We don't really want novices playing with it if the code might have become broken. RFC1644 is after all a 1994 "Experimental Protocol" that hasn't gained acceptance. The only reason I can see for keeping the code now would be as a basis for experimenting with a similar new protocol - and I'm not aware of anyone looking at that. Richard -- Richard Wendland richard@wendland.org.uk