On Mon, Feb 18, 2008 at 04:15:36PM +0800, Kacheong Poon wrote: > One problem of implementing this in user land is that we > don't allow shrinking of the receive buffer (which in turns > control the TCP receive window). The reason is that TCP > should not shrink the receive window (moving the right edge > of the receive window left). In order to reduce the receive > window, TCP needs to keep the right edge fixed until it can > be moved right when the window is now of the reduced size. > We don't have this hence we don't allow shrinking of the > receive buffer.
Good to know. > The above means that an app cannot use setsockopt(SO_RCVBUF) > to fine tune the TCP window, which can only be changed in > one direction. If there is a mistake, it cannot be corrected. Two points. First, I imagine that fixing this so that the app can reduce SO_RCVBUF should not be nearly as hard as adding TCP auto-tuning to Solaris. Second, we don't have to fix this anyways: since SSHv2 has its own flow-control mechanisms we can still throttle the sender at the SSHv2 layer, even if we can't shrink SO_RCVBUF. As long as we're able to open the throttle on TCP by enlarging the SO_SND/RCVBUFs _and_ we can still slow down senders (we can) then we should be OK, with some wasted memory IF the TCP stack reserves as much memory as requested via SO_SND/RCVBUF. The benefit of auto-tuning TCP buffer sizes at the app layer is that twofold: a) with SSHv2 we can actively measure RTTs on the receive side (and send side) -- add actual used bandwidth and we can heuristically decide when the BDP (buffer sizes) should be increasing or decreasing, b) we need to anyways because SSHv2 has its own channel flow control mechanism and we need to be able to dynamically manage SSHv2 channel window sizes if we're to take advantage of TCP auto-tuning (whatever layer it happens to be done in). (b) in particular is a strong argument for auto-tuning TCP in ssh/sshd. Nico --
