"Ashish Awasthi" <[EMAIL PROTECTED]> 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 out
> 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

Bill Moran
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to