nanog mailing list archives

Re: Data on latency and loss-rates during congestion DDoS attacks


From: Saku Ytti <saku () ytti fi>
Date: Sat, 25 Jan 2020 09:12:20 +0200

On Sat, 25 Jan 2020 at 05:30, Amir Herzberg <amir.lists () gmail com> wrote:

That's actually roughly the range of losses we focused on; but it was based on my rough feeling for reasonable loss 
rates (as well as on experiments where we caused losses in emulated environments), and a reviewer - justifiably - 
asked if we can base our values on realistic values. So I would love to have real value, I'm sure some people have 
these measured (I'm actually quite sure I've seed such values, but the challenge is recalling where and finding 
it...).

DDoS is very very cheap, if there is a single global egress for given
interface then the DDoS traffic can easily be 100 times the egress
capacity (1GE egress, 100GE DDoS). I'm very skeptical if FEC will
help, I think this is case of cat and mouse, based on data you see now
it may seem reasonable, but now is only result of minimum viable ddos,
which is trivial to increase should need occur. Similarly DDoS attacks
are excessive dumb often, like dumb UDP ports which are easy drop, but
should we solve protection well for these, it's trivial to make it
proper HTTPS TCP SYN.

Also, latency values (under congestion) would be appreciated. Also here, we used a range of values, I think the 
highest was 1sec, since we believe that under congestion delays goes up considerably since many queues fill up [and 
again I seem to recall values around this range]. But here the reviewer even challenged us and said he/she doubts 
that delays increase significantly under network congestion since he/she thinks that the additional queuing is 
something mostly in small routers such as home routers (and maybe like the routers used in our emulation testbed). So 
I'll love to have some real data to know for sure.

Backbone device interface can add hundreds of milliseconds during
congestion, but more commonly we're talking about tens of milliseconds
during congestion and low microseconds to high nanoseconds outside
congestion.
Backbone device buffer space is highly googlable, BRCM
trident/tomahawk styte boxes have very little, but they are more
intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar,
EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper
Paradise, Broadcom Jericho all will buffer high tens of milliseconds
to low hundreds.

-- 
  ++ytti


Current thread: