On Thu, 24 Jun 2004, Steve Peterson wrote:
> 
> That's interesting.  I'm trying to reconcile that with the behavior I saw 
> when I used to run a stock FreeBSD 4.x distro on my old P90 as a 
> firewall.  I could ping all day and never have a dropped packet.  Same 
> thing at my parents' house with their Netgear WGT624.

Sorry, I didn't know you were talking about pings.  If you're only doing
(non-flood) pings on an unsaturated path, then *any* packet loss indicates
trouble.  But if there's congestion from another source, then pings may
get dropped as well, depending on the algorithm for choosing which packets
to drop.

The usual guideline for TCP is that any packet loss *other than due to
congestion* above about 1-2% will seriously impact performance.  Although
TCP's retransmission mechanism was originally designed to cope with
unreliable links, packet loss has become so important as a means of
congestion feedback that congestion control effectively "owns" packet
loss, and doesn't share it without sending performance into the toilet.

You don't say what path you were pinging.  Trying different hops in the
path can often identify the location of the trouble by "differential
packet loss".

On Thu, 24 Jun 2004, Chris Buechler wrote:

> The above explanation from Fred isn't exactly correct.  TCP *will* pass
> data as fast as the sender can produce and the receiver can receive.
> Dropped packets are by no means a method of throttling, and shouldn't
> happen frequently if your connection is solid, which it sounds like it
> is. 

Think about what you just stated: "TCP *will* pass data as fast as the
sender can produce and the receiver can receive".  If the sender or
receiver is slower than the network, then of course the network can keep
up.  But if the network is the limiting factor, it can't possibly "pass
data as fast as ...".  TCP doesn't know how fast the network is, so it
just sends faster and faster until it gets in trouble.  There's a new
thing called Explicit Congestion Notification to allow it to find out
about congestion before it gets to the point of dropping packets, but
that's not yet widely supported, and it needs to be supported by all the
routers in the path to be fully effective.

Due to the "separation of layers" in typical implementations, even when
the directly-connected link is the limiting factor, TCP doesn't know
enough to limit its send rate.  It just keeps handing off packets to IP
faster and faster until the IP code *on the same machine* decides the
queue is too long and starts dropping them.

> I run a half dozen netmon graphs on my second screen constantly, behind
> a m0n0wall box (netmon pings a given host and displays a graph in real
> time http://www.nullsoft.com/free/netmon/).  Therefore, I see all
> dropped packets.  It drops about 1-2% of pings, which I've found is

That's not "all dropped packets".  I'll bet it doesn't show dropped *TCP*
packets, which would require capturing the traffic and examining the
pattern of sequence numbers and ACK numbers.  You need to look at packet
traces, not graphs.

					Fred Wright