From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 12:35:45 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 D822716A41F; Wed, 21 Sep 2005 12:35:45 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B4843D48; Wed, 21 Sep 2005 12:35:44 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8LCZiLD009116; Wed, 21 Sep 2005 14:35:44 +0200 Message-ID: <4331539D.9030204@wm-access.no> Date: Wed, 21 Sep 2005 14:35:41 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> In-Reply-To: <20050921114511.D34322@fledge.watson.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 12:35:46 -0000 Robert Watson wrote: > > So if someone could generate some application pseudo-code that suggests > what specifically is necessary from the socket layer in order for the > application to function, we can talk about socket service extensions > that might support the application. For example, a way to query > detailed error information rather than just the SO_ERROR socket option. > Or a longer haul PMTU data gathering mechanism for UDP sockets. Or ways > for UDP applications to more usefully query the kernel for the TCP PMTU > data already being recorded. > > It sounds like for the bandwidth tester, IP raw sockets already provide > what you need, since you want to be able to do fairly irregular UDP > things (i.e., receive UDP packets with bad checksums, and see fragments). > IP raw sockets? Sure, Everything can be solved the complicated way :o) Some userland applications could benefit from having the option of DF flag set/unset. What about applications that wants to have a way of optimizing UDP transfers in their network path? Some networks filter icmp and fragments irresponsibly (imho) and sometimes the combination of two or more networks that would cause problems for multicast/video/voip applications. Sometimes in one network udp packets need fragmenting and in the next network fragments need to get reassembled to pass a firewall which in turn runs out of reassembling resources. ( It is more common to block icmp messages about reassembly problems than DF problems IF a message is generated in the first place. ) Sure, all of this could be fixed the complicated way but what if one already has an application that runs in unprivileged userland. How many lines of code would a simple socket option plus the "tuning" code require? -- Sten Daniel Sørsdal