Daniel Carosone writes:
> On Thu, Sep 30, 2004 at 02:11:00PM -0400, Steven M. Bellovin wrote:
> 
> > TCP interprets dropped packets as congestion loss, and slows down its 
> > transmission rate rather drastically.
> 
> If the macs are running OS/X, you may also be suffering additional
> trouble because they have the old freebsd stretch-ack bug.

Ok, thank you both for the pointers -- I've just done some
reading of RFC2525, but it looks like that's a bug at the
receiver end?  Here I'm getting very low throughputs from OS
X to NetBSD, so it's probably not that...?

> The problem can probably be seen quite easily with a packet capture
> and tcptrace TSG plots, but you need to know what you're looking at.

So, I've not used tcptrace before: but I'd be looking for
more than 2 segments (white arrows) between successive steps
of the green ACK line?  Looks like during regular flow it's
always one or two segments between each step.

TSG recorded on NetBSD for MacOS->NetBSD transfers shows
approx 10ms bursts of traffic (a few dozen segments),
separated by gaps of a second or two.  Typical structure: at
the end of a burst I see segments 1-2-6-7, followed by a
second or so gap with no ACKs, then 3-4-5 out of order, and
resends of 6-7.  Then a few ms of good traffic, and repeat.

Sometimes more than one range of segments is out-of-order,
and occasionally I can see repeated ACKs of the last
in-sequence segment in the gap.  Does this shed any more
light?  Thanks for pointing out tcptrace, in any case. :-)

Trying several different cables and ports hasn't helped,
BTW, but replugging and ifconfig ste0 down then up again
occasionally makes the problem go away for a while.

Mark <><