From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 01:03:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 6E0AA16ACDD; Sun, 3 Jul 2005 01:02:53 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC31C45475; Sun, 3 Jul 2005 00:54:52 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 1DC785DA38; Sat, 2 Jul 2005 17:07:35 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 5F6865CC3A for ; Mon, 25 Oct 2004 22:19:09 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 213C555874; Tue, 26 Oct 2004 05:19:09 +0000 (GMT) (envelope-from owner-freebsd-arch@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2E21A16A4DA; Tue, 26 Oct 2004 05:19:08 +0000 (GMT) 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 A26E716A4CE; Tue, 26 Oct 2004 05:19:05 +0000 (GMT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC4843D39; Tue, 26 Oct 2004 05:19:04 +0000 (GMT) (envelope-from suz@crl.hitachi.co.jp) Received: from flora210w.uki-uki.net (localhost [IPv6:::1]) by v6.hitachi.co.jp (8.12.11/8.12.11) with ESMTP id i9Q5J1Oc046258; Tue, 26 Oct 2004 14:19:02 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Message-ID: From: SUZUKI Shinsuke To: peter.lei@ieee.org X-cite: xcite 1.33 In-Reply-To: <4179ACB8.4020108@ieee.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> User-Agent: Wanderlust/2.11.32 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-arch@freebsd.org Errors-To: owner-freebsd-arch@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: Cc: freebsd-net@freebsd.org, andre@freebsd.org, freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:03:20 -0000 X-Original-Date: Tue, 26 Oct 2004 14:19:02 +0900 X-List-Received-Date: Sun, 03 Jul 2005 01:03:20 -0000 >>>>> On Fri, 22 Oct 2004 19:58:32 -0500 >>>>> peter.lei@ieee.org(Peter Lei) said: > While the SCTP API hasn't gone through last call, it's fairly > stable and we have both "converted" many applications from TCP > to SCTP using the sockets API, as well as had portability between > the KAME SCTP stack and the linux stack for some test applications > used at the last interop event (except for the standard sockets > issues that one runs into even for TCP like no sin_length field > in the sockaddr struct). > I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. > The major changes to our SCTP code when it gets committed into KAME > has been that of code format/style. What I found was the following two issues. Although these two are technically quite trivial, what I was fearing was a lack of report to KAME, since this may mean a lack of KAME-SCTP users. - inconsistency between KAME specific kernel code and SCTP leads to an kernel compilation error. Of course, it's a technically trivial bug and our own bug. - including SCTP in getaddrinfo() causes 'configure' script error in many ports applications. This is also a trivial problem, and maybe specific to KAME SCTP. And some of such ports are already fixed when I encounter this problem. (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) But now I understand that lack of report does not mean a lack of testing users (since SCTP-lovers seems communicating directly to your team). So I can be much more optimistic now, and don't object to merging it into -current, since such trivial bugs can be fixed easily in -current. (I myself haven't tested SCTP very well, so I cannot comment on its stability itself. But at least, SCTP does not seem to affect the behavior of other protocols) Thanks and sorry if you feel my previous comments were insulting... ---- SUZUKI, Shinsuke @ KAME Project _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"