On Fri, 31 Mar 2000, Mark Allman wrote:
> The stack does fast retransmit.  I can't tell if that is the problem
> here or not because it looks like the trace has been snipped.
> But....

It's snipped above and below the part I quoted, but I didn't remove
anything from within the trace.

> >  [ ack ack ack ]
> 
> [[ I am not sure what the snipped ACKs look like.  If they have an
>    updated advertised window they are probably reseting the dupack
>    counter. ]]

That was just my way of saying that the remote side is sending more
ACKs... I didn't actually remove any ACKs.

> It would be interesting to see the entire trace (the binary version
> would be especially nice).  What concerns me about this is the
> apparent long delay between receiving the last ACK and
> retransmitting the missing segment.  (I say "apparent" because there

I didn't save a binary version, and I can't seem to duplicate the
problem with a 1.4X kernel. I'll try reverting to my previous kernel and
see if the problem happens again though.
-- 
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 24 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++