<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 6, 2014 at 4:26 PM, Colm MacCárthaigh <span dir="ltr"><<a href="mailto:colm@stdlib.net" target="_blank">colm@stdlib.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't see anyone disputing my example, and I'm not calling out RRLs ability to dampen a reflection attack. I'm saying that RRL can be used to counter-attack your users.  Let's say a busy website gets 1,000 QPS of "real" user queries. If I want those queries to survive say with 2 retries, then I need to let through 40% of traffic to have a 95p confidence of them getting an answer. Yes, I'll have mitigated the reflection to 4Gbit/sec, but meanwhile users will be seeing increased resolution times and timeouts. </blockquote>

</div><br>My recommendation (which Vixie and Vernon disagree with) is to use RRL with slip=1 -- return TC=1 responses to all queries over the limit.  This ensures your legitimate users can get through with a TCP request, rather than having to attempt multiple retries before learning to retry over TCP.  Does slip=1 address your concerns?</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Of course TCP isn't perfect -- it has higher latency and per-connection costs -- but at least it ensures your legitimate users can't be affected by the RRL.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Damian</div></div>