From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 17:57:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D1A716A4CE for ; Thu, 21 Oct 2004 17:57:04 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94D7743D54 for ; Thu, 21 Oct 2004 17:57:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79111 invoked from network); 21 Oct 2004 17:55:39 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 17:55:39 -0000 Message-ID: <4177F875.2822A51E@freebsd.org> Date: Thu, 21 Oct 2004 19:57:09 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@icir.org References: <20041021173145.1AE6477A9D0@guns.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 17:57:04 -0000 Mark Allman wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > I haven't fully digested this yet. But, I'll voice my distaste for > implementing things that just seem to "Make Sense". That's a model that > has been used and is used by other operating systems and those of us who > watch packets can attest that things that "Make Sense" often don't and > likely would have benefitted by a bit more thought and a bit more > vetting. I would be happier if something like this were vetted out a > bit more (written up, digested by folks, etc.) before it went into > anything but someone's experimental kernel. Just my two cents. Sure. To make you sleep better it will be disabled by default (like T/TCP) and possibly even not compliled in by default (#ifdef'd). If enabled and compiled in it does not automatically enable itself for all and everything. The application has to enable it on the socket as well. A writeup will follow once I get there. I made this request before I start working on it to prevent to waste my time on it if people wanted to religiously stick to T/TCP. -- Andre