From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 19:11:52 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 5A57C16A41A for ; Tue, 11 Dec 2007 19:11:52 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5197113C465 for ; Tue, 11 Dec 2007 19:11:52 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 187B81B98826; Tue, 11 Dec 2007 11:11:52 -0800 (PST) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id F1D5428083; Tue, 11 Dec 2007 11:11:51 -0800 (PST) X-AuditID: 11807134-a7199bb000005aa1-b8-475ee0f755b5 Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id C2EB128087; Tue, 11 Dec 2007 11:11:51 -0800 (PST) Message-Id: From: Chuck Swiger To: rihad In-Reply-To: <475E3DB6.4030203@mail.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 11 Dec 2007 11:11:51 -0800 References: <475D6FD7.2000500@mail.ru> <475E3DB6.4030203@mail.ru> X-Mailer: Apple Mail (2.915) X-Brightmail-Tracker: AAAAAA== 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: Tue, 11 Dec 2007 19:11:52 -0000 On Dec 10, 2007, at 11:35 PM, rihad wrote: >> Pipes and queues are two different things; a pipe simulates a >> network link, and a queue is used to hold packets which are >> backlogged because they are arriving faster than the outbound link >> (ie, a pipe) can transmit them. > So you mean queues are only used on the sending side? (the box is > acting as a router) and that their purpose is to diminish packet > loss rate due to network congestion? Now I get it, thanks. Queues are used to buffer packets before sending. For a router, this affects traffic in both directions, but it's normally the case that that Internet<->router link is slower than the router<->LAN link. >>> What if I set it to 10000 slots, why should it wait to fill the >>> queue before starting to send stuff out the network interface? >> Well, it *doesn't* wait for the queue to be filled before starting >> to send stuff out the network. > 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... -- -Chuck