From owner-freebsd-questions@FreeBSD.ORG Fri Mar 31 07:27:08 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E191216A41F for ; Fri, 31 Mar 2006 07:27:08 +0000 (UTC) (envelope-from awasthi.ashish@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5269443D48 for ; Fri, 31 Mar 2006 07:27:08 +0000 (GMT) (envelope-from awasthi.ashish@gmail.com) Received: by wproxy.gmail.com with SMTP id i21so624746wra for ; Thu, 30 Mar 2006 23:27:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aLMj4s+IYIgf76By8Dp9UP4LBEcFWxWTz4L5jiPkqxIBjw/7otSJiKBSYNIoR8Xk/pCh2PaJkld4GkSrzXmWU+vIsTaAeaVTHP2U+cLV/1YtNvf7Z3xkWV9ILXduocVQij/dAJC+45noDNjX30jM1kMRfk6BxGz30m8VSy3kPh0= Received: by 10.65.225.9 with SMTP id c9mr91492qbr; Thu, 30 Mar 2006 23:27:04 -0800 (PST) Received: by 10.65.252.10 with HTTP; Thu, 30 Mar 2006 23:27:04 -0800 (PST) Message-ID: <5289d17a0603302327o69228ac0l611c434176d0a31c@mail.gmail.com> Date: Fri, 31 Mar 2006 02:27:04 -0500 From: "Ashish Awasthi" To: "Bill Moran" In-Reply-To: <20060330092327.3f4fc954.wmoran@collaborativefusion.com> MIME-Version: 1.0 References: <5289d17a0603291735u194807cbu853b438edc80049b@mail.gmail.com> <5289d17a0603291736s2f05bb55m293e2ec32af8a3af@mail.gmail.com> <20060330092327.3f4fc954.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions@freebsd.org Subject: Re: Packet drops and queue length upon bandwidth limiting in PF X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 07:27:09 -0000 On 3/30/06, Bill Moran wrote: > > "Ashish Awasthi" wrote: > > > I am a relative newbie, so please don't flame me if my question doesn't > make > > sense. > > > > In a network experiment to determine appropriate length of router > buffers, I > > am using pfctl on FreeBSD 5.3 to limit the bandwidth to 100 Mbps on a 1 > Gig > > link and limit the queue to 240 packets, and I use iperf for sending ou= t > > data. Connection is maintained between two routers running FreeBSD 5.3, > > connected by a 1 Gig link. I monitor on sender the pfctl and iperf > > statisitcs. > > > > As I see the iperf throughput go down from 94 Mbps to 50 Mbps and then > rise > > again in accordance with the classic sawtooth curve of TCP, it is clear > that > > there must have been a packet drop, but "pfctl -s -queue -v -v" at the > > sender shows 0 losses and 0 drops. Moreover, the queue length as > reported > > never overflows. Even netstat shows 0 retransmissions! > > > > I tried this with queue lengths of 50, 100, 240, 10 and 5. Only when > queue > > length is on the order of 5 or 10 do I see packet drops in pfctl report > (and > > also retransmissions in the netstat report); however, since I have > limited > > the bandwidth and the outgoing traffic is shaped by this limitation, it > is > > clear that there must be some packet losses in other cases as well. > > > > So, I tend to think that some other queueing is occuring apart from the > > ALTQ, and drops are occuring there. If so, how can I obtain those > > statistics? > > You're making a lot of assumptions about how things work, so I'll follow > in kind. > > I would assume that pf is sending ICMP source quench messages to the > sending machine to avoid overflowing its queues. If it's proactive > in doing this, it would never overflow, except in the case where the > queue is so short that it can't reply with a source quench fast enough. > To me, this would be expected behaviour. A little packet sniffing should > show whether this is what is actually happening or not. > > As a side note, this is why arbitrarily blocking all ICMP messages is a > bad > idea. > > -- > Bill Moran Hi, Thanks for your response. However, the problem still remains. I did check for ICMP packets at both the source and the router, but there are NO source quench packets at all in the tcpdump traces. Where should I be looking? Any suggestions? Thanks a lot! Ashish