Nicolas Williams wrote:
> 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.
There is another problem to fine tune the TCP receive window.
The problem is that TCP uses 16 bits to represent the receive
window. For window larger than 64KB, TCP uses a scaling factor.
But this factor is negotiated at the start of the connection.
So your app needs to start with the "max" (according to your
app) buffer size so that the correct scaling factor is negotiated
at connection set up time.
> 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.
Since the app will not see packet drop, the only possible
indicator of congestion is the RTT of ssh data. But this can
be misleading some time. For example, TCP can recover from
data lost without a timeout. From the app's perspective, it
may be seen as a jitter. So the app may be very slow to respond
to congestion events. And the app may need to second guess
the congestion window used in TCP, as this will affect the
sending rate. I suspect that it will be quite tricky to do it
right at the app level.
> 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.
How does the current implementation of the flow control work?
Does it partition the socket buffer into equal sizes for all
the channels? Or does it dynamically change that?
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
