I've thought about these issues a bit recently ..

> 1) The input side of the TCP stack needs to actually check that there
>    is space available before calling sbappend().  This will prevent
>    the socket from consuming more than its share of space, but may
>    lead to performance issues in this case because only a few packets
>    will fit in the socket buffer, the window will rapidly shrink, and
>    a bunch of packets already on the network will end up being thrown
>    away.

I suggested this recently to a TCP guru and he recoiled in horror.
Apparently, retracting the leading edge of the window is not allowed
and is known to cause interoperabilty problems/crashes in other TCP's.
Don't Do It...

> 2) It may be worth changing sbcompress() to compact clusters as well.
>    This can be tweaked to check for some threshold; e.g. allow up to
>    1/2 of the space to be wasted to avoid excessive copying.

This sounds like a better approach.  I'm not sure the threshold is
necessary; if the receiver isn't reading data fast enough to consume
data at the rate it's being received, you'll get into buffer space
troubles in any event so it would make sense to copy.

Perhaps the threshold should be based on the number of mbufs in the
chain.. i.e., compress if you have more than 3-4 mbufs in the socket
buffer.

> 3) It's unclear to me that SSH should be setting TCP_NODELAY at all
>    for non-interactive use.  (This may actually be fixed in later
>    versions.)

Yeah, this seems.. poor.  

						- Bill