From owner-freebsd-net@FreeBSD.ORG Wed Dec 12 12:13:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25B4916A419 for ; Wed, 12 Dec 2007 12:13:00 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx38.mail.ru (mx38.mail.ru [194.67.23.16]) by mx1.freebsd.org (Postfix) with ESMTP id C6A0113C447 for ; Wed, 12 Dec 2007 12:12:59 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from [217.25.20.94] (port=45771 helo=[217.25.20.94]) by mx38.mail.ru with esmtp id 1J2NKM-000E5T-00; Wed, 12 Dec 2007 11:52:27 +0300 Message-ID: <475FA13B.8060208@mail.ru> Date: Wed, 12 Dec 2007 12:52:11 +0400 From: rihad User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Chuck Swiger References: <475D6FD7.2000500@mail.ru> <475E3DB6.4030203@mail.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Pipe queues 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, 12 Dec 2007 12:13:00 -0000 Chuck Swiger wrote: > On Dec 10, 2007, at 11:35 PM, rihad wrote: >> This ipfw manpage section was the reason I asked (sorry for the >> formatting). What's with the "queuing delay" part? I'm totally confused. >> >> queue {slots | sizeKbytes} >> Queue size, in slots or KBytes. Default value is 50 slots, >> which >> is the typical queue size for Ethernet devices. Note that >> for slow >> speed links you should keep the queue size short or your >> traffic >> might be affected by a significant queueing delay. E.g., 50 >> max- >> sized ethernet packets (1500 bytes) mean 600Kbit or 20s of >> queue on >> a 30Kbit/s pipe. Even worse effects can result if you get >> packets >> from an interface with a much larger MTU, e.g. the loopback >> inter- >> face with its 16KB packets. > > The issue is that if you have a really slow upstream link, you can end > up queuing many seconds worth of traffic using the default queue size-- > depending on the priorities, you might have traffic being buffers so > long that it starts breaking connections or causing needless TCP retries... > Oh, now I get it, thanks! Perhaps the authors should have stated it clearly that instead of queuing packets for too long you'd better drop them, otherwise upper-layer retransmissions might cause multiple copies of a packet to arrive at the client and cause errors (would they?). This may be clear to networking people but it isn't so clear to someone like me trying to figure out what's going on. Now I know what technical documentation is all about :)