[tahoe-dev] connection timeouts on VG2

[David-Sarah Hopwood]

On 26/03/12 22:05, Brian Warner wrote:
> On 3/26/12 4:54 AM, Greg Troxel wrote:
> 
>>   If the keepalive is set to 120s, then it seems simply broken (and
>>   likely easy to fix) to have the keepalive happen at 240s. 120s as a
>>   keepalive timer should mean that a keepalive is sent 120s after the
>>   last recorded transmission.
> 
> Yeah, I have to admit it's kind of weird. It's because I designed that
> code to minimize all forms of overhead:
> 
>  * don't send any extra network traffic unless it's really necessary
>  * don't replace/reset the timer very frequently

Is there reason to believe that timer resetting is an expensive operation?
It doesn't seem as though it should be.

>>   It's interesting to consider not keeping connections open, but
>>   instead opening them on demand and closing after say 1m of idle
>>   time. There's a slight latency hit, but it should avoid a lot of
>>   issues and result in a lot fewer standing connections.
> 
> Yeah, I suspect that when we get to tahoe-over-HTTP, it'll end up
> working that way. Sort of lowest-common-denominator, but that's
> practicality-over-purity for you. For data-transfer purposes, you really
> want to leave that connection nailed up (otherwise you lose a lot of
> bandwidth waiting for TCP to ratchet up the window size), but of course
> that gets you right back in the same boat.

HTTP 1.1 persistent connections are an important latency optimization
and I think we should support them when we move to Tahoe-over-HTTP.
That's somewhat independent of whether we use HTTP keepalives to attempt to
keep idle connections open for longer than 115 seconds [*]. This is a
tradeoff between the complexity of sending keepalives and the latency hit of
sometimes opening a new connection. If the complexity is in some already-
implemented HTTP library code, then there probably isn't a significant
downside to enabling keepalives. If not, then it should depend on whether
we think the latency hit is significant after measuring it in typical usage.


[*] 115 seconds is the default HTTP keepalive time for Firefox:
    http://kb.mozillazine.org/Network.http.keep-alive.timeout
    (Internet Explorer uses 60 seconds:
    http://support.microsoft.com/kb/813827 )

    So, any firewall that drops a connection after less than 115 seconds
    idle time (plus an error margin) is irretrievably hosed, since that
    would consistently break Firefox.

-- 
David-Sarah Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120327/15459b79/attachment.pgp>