The original 3 seconds is from 1989. I don't believe that a 26 years old value is a sound argument to bump it to 7 seconds IMO.
This does not mean the default is correct, however, but increasing it 3.5 times doesn't make me uneasy considering the security implications. My 2 cents. On Sun, Mar 15, 2015 at 5:36 PM, Nils Goroll <[email protected]> wrote: > Hi, > > some time has passed since my initial email regarding this suggestion and > it > still holds. > > Unless there is a strong argument against it, I think we really should > increase > the default timeout_req to 7 seconds. I think the argumentation for this > value > is sound and I haven't found any reasons against it. > > Please keep this suggestion separate from the suggestion to re-introduce > SO_LINGER. I still need to do production system tests with it. > > Nils > > On 26/02/15 11:27, Nils Goroll wrote: > > This tcpdump output illustrates an issue we seem to have with default > Linux tcp > > timeouts and the default timeout_req of 2 seconds: > > > > 16:47:44.542049 IP client.49550 > varnish.80: Flags [S], seq 29295818, > win 4380, > > options [mss 1460,sackOK,eol], length 0 > > 16:47:44.542080 IP varnish.80 > client.49550: Flags [S.], seq > 3652568857, ack > > 29295819, win 29200, options [mss 1460,nop,nop,sackOK], length 0 > > 16:47:44.542250 IP client.49550 > varnish.80: Flags [.], ack 1, win > 4380, length 0 > > 16:47:46.080501 IP client.49550 > varnish.80: Flags [P.], seq 1:1453, > ack 1, win > > 4380, length 1452 > > 16:47:46.080528 IP varnish.80 > client.49550: Flags [.], ack 1453, win > 31944, > > length 0 > > 16:47:48.082783 IP varnish.80 > client.49550: Flags [F.], seq 1, ack > 1453, win > > 31944, length 0 > > 16:47:48.083070 IP client.49550 > varnish.80: Flags [.], ack 2, win > 4380, length 0 > > 16:47:48.350763 IP client.49550 > varnish.80: Flags [P.], seq 1453:2905, > ack 2, > > win 4380, length 1452 > > 16:47:48.350792 IP varnish.80 > client.49550: Flags [R], seq 3652568859, > win 0, > > length 0 > > > > The packet at 16:47:46.080501 contains the first part of a request up to > the > > start of a very long cookie line. > > > > At 16:47:48 varnish closes after reaching timeout_req of 2s. Then, the > client > > immediately acks. > > > > My understanding is that the varnish->client ack 1453 got lost and the > client > > did not get around to retransmit seq 1:1453 before we timed out. > > > > > > The most helpful online reference regarding recommended initial tcp > > retransmittion timeouts I have found so far is > > http://tools.ietf.org/html/rfc6298#ref-PA00 > > > > In summary, an initial timeout (RTO) of 1s is now recommended, but the > former 3s > > RTO remains valid. So, for any client following the former 3s > recommendation, > > current we don't even tolerate a single packet retransmission after 3way > is > > complete. For those clients following the new 1s recommended RTO, timing > is also > > really tight it seems unlikely that we tolerate retransmission of two > packets. > > > > Based on this, I'd suggest to raise the default timeout_req to 7 seconds > to > > allow for two retransmissions at RTO=3. > > > > This seems to be particularly relevant with the growing popularity of > mobile > > clients. > > > > The risk is increased resource usage for malicious requests. To address > it, I'd > > suggest to document that lowering timeout_req can be an option to > mitigate > > certain DoS (slowloris) attacks. > > > > > > Nils > > > > > > _______________________________________________ > > varnish-dev mailing list > > [email protected] > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > > > > _______________________________________________ > varnish-dev mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev >
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
