proper SACK behavior?

[Greg Troxel <gdt%ir.bbn.com@localhost>]

Is our SACK implementation believed to be complete in current?
netbsd-4?  I noticed some sluggishness today on remote ssh, and went to
investigate.  I found that when a packet is lost tcp correctly resends
it on the 3rd dup ack, and then doesn't retransmit the next outstanding
segments on subsequent dup acks (which is good, because they have been
sacked but not acked).  The retransmit makes it, and after the ack
arrives new packets are sent and the rate recovers.  But there's
essentially a timeout, rather than a halving of cnwd.  It's a timeout of
actual RTT (which is large due to buffering, up to 300 ms from the 7 ms
unloaded RTT (FiOS)), rather than the estimate.

To analyze this, I ran a program that just connects to remote discard
port and sends 5 MB, capture dthe packets at the sender, and then ran it
through tcpdump2xplot.  I've put the resulting xplot up at

  http://www.lexort.com/netbsd/

Use pkgsrc/graphics/xplot to view this.  The bottom line is the ack, the
top the receiver's window, vertical marks outgoing packets, and green
vertical marks sack contents.

It seems that the ack line doesn't lose much if any progress, but it
also sems like the pipe is not kept full.

Should the sender be sending new segments on receipt of each ack where
sack acks new data?