suggesting to increase timeout_req default to 7 seconds

[Federico Schwindt]

Of course *does make me uneasy*.

On Sun, Mar 15, 2015 at 10:33 PM, Federico Schwindt <fgsch at lodoss.net>
wrote:

> 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 <slink at schokola.de> 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
>> > varnish-dev at varnish-cache.org
>> > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>> >
>>
>> _______________________________________________
>> varnish-dev mailing list
>> varnish-dev at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20150315/54cc96fe/attachment.html>