From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 511B53B25D; Sun, 1 May 2016 11:51:11 -0400 (EDT) Received: by mail-vk0-x232.google.com with SMTP id o133so40578474vka.0; Sun, 01 May 2016 08:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LVKbxJ0n2VC6N9e9uIg0oKR5FKVWMCKxQUrVFnC7J2A=; b=FEzQnXC0KI031mrVag0zyu103GXlS9cNiDTSi9mMSE2Js7UBPO5rO33xsNkDLcnHGa XpbhehMRjLpaLK5lI3i7lVFPDB1N6GDdPMYzzKxKGELq9CXIsMMCyeDuh3Ya+V30UvJz qxa/ot/D27jipFNzv/K7Pc7LY7+reRtKQAT6CfA0Snyc8mXnU6VcajSXLoCfwvg/8PTD kQrAQQqAdZdHip/ZtOYrTpKxWwD/5GNp/0EYNfUw7uJXQn5QVwuXTUMvhTN72aq+dzy4 Smg0ofqJmZB/eD7drW6jzsdFIc1Yncd6nwKHhVkBGSzzhxQt+DvLJmS0HCDv0goojP5Z DAZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LVKbxJ0n2VC6N9e9uIg0oKR5FKVWMCKxQUrVFnC7J2A=; b=EUOE7Cki26jDfHHJCdywmesU8tMmwahnMwhhURPaJycj7tOMYx7bjdRN0+Fp6UOH57 VhJ4UxgTeFbGJAeDuMqqltH2zeqOhjKFNQEqwNPool0QgAjwrZYbi0AbKcVhuKfJJdSl EAs00Vtzo6s7naqOvDEG0rX84TcjFKMU4YY3rY2vJ+uy7GzpzIJ8bg0GZ1SGF+fvG9K5 Eqmri0cO0lBm5TRtw1/GIt1ZoK9ysYJjXKF8SPgOF5p4GcuBnErq6TTzLRv9fZ5WTEdj h0Tz4Xp959HTgRZ+PY13vKZOzqDh1E65VjJuc9yQCW3XaZIUO+dqYpO447LvmUb6kisS OX1Q== X-Gm-Message-State: AOPr4FXb3LL3NDUqbgbJVJFLgn+Vob0Y8abL09i2bsMe79ClL5cJmEuERARKJ+sDIjhpnFeWUYPmdpx0aV8Fyw== MIME-Version: 1.0 X-Received: by 10.176.2.235 with SMTP id 98mr17054412uah.86.1462117870879; Sun, 01 May 2016 08:51:10 -0700 (PDT) Received: by 10.176.1.138 with HTTP; Sun, 1 May 2016 08:51:10 -0700 (PDT) Received: by 10.176.1.138 with HTTP; Sun, 1 May 2016 08:51:10 -0700 (PDT) In-Reply-To: References: <57258F41.8040600@candelatech.com> <1462114043.512818296@apps.rackspace.com> Date: Sun, 1 May 2016 18:51:10 +0300 Message-ID: From: Jonathan Morton To: "David P. Reed" Cc: Dave Taht , ath10k , "codel@lists.bufferbloat.net" , Ben Greear , make-wifi-fast@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113b14e8504e8b0531c9d825 Subject: Re: [Make-wifi-fast] fq_codel_drop vs a udp flood X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 15:51:11 -0000 --001a113b14e8504e8b0531c9d825 Content-Type: text/plain; charset=UTF-8 > Maybe I missed something, but why is it important to optimize for a UDP flood? I draw a firm distinction between a "simple" UDP flood as described in this thread, and a DDoS. The latter is much harder to mitigate than the former. There is value in being able to cope with an unresponsive, high volume UDP flow while leaving the network as a whole responsive. To do so on a consumer-grade router requires the coping mechanism to be at least moderately CPU efficient. It's all too easy to mis-design or mis-implement an otherwise useful protocol so that it looks like a flood. There need not be any malice involved. A case in point would be the accidental NTP DDoS inflicted by a particular brand of router on one specific NTP server (and the network hosting it) after a widespread blackout was resolved. Not only was the IP address hardcoded in that router, but it retried every second instead of an exponential backoff. Both are NTP protocol violations. The server quickly became too overloaded to respond at all, leading to a stable flooding state. But the traffic volume from each individual router was, in absolute terms, miniscule. One can easily imagine a faulty uTP implementation failing to perform congestion control. That would result in a UDP flood over a relatively small number of flows, which is exactly the sort of scenario we can realistically control with a little effort. How many fly-by-night BitTorrent clients are there out there? The protocol is increasingly used in game updater-launchers, too. - Jonathan Morton --001a113b14e8504e8b0531c9d825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> Maybe I missed something, but why is it important to op= timize for a UDP flood?

I draw a firm distinction between a "simple" UDP f= lood as described in this thread, and a DDoS.=C2=A0 The latter is much hard= er to mitigate than the former.=C2=A0 There is value in being able to cope = with an unresponsive, high volume UDP flow while leaving the network as a w= hole responsive.=C2=A0 To do so on a consumer-grade router requires the cop= ing mechanism to be at least moderately CPU efficient.

It's all too easy to mis-design or mis-implement an othe= rwise useful protocol so that it looks like a flood.=C2=A0 There need not b= e any malice involved.

A case in point would be the accidental NTP DDoS inflicted b= y a particular brand of router on one specific NTP server (and the network = hosting it) after a widespread blackout was resolved.=C2=A0 Not only was th= e IP address hardcoded in that router, but it retried every second instead = of an exponential backoff.=C2=A0 Both are NTP protocol violations.=C2=A0 Th= e server quickly became too overloaded to respond at all, leading to a stab= le flooding state.=C2=A0 But the traffic volume from each individual router= was, in absolute terms, miniscule.

One can easily imagine a faulty uTP implementation failing t= o perform congestion control.=C2=A0 That would result in a UDP flood over a= relatively small number of flows, which is exactly the sort of scenario we= can realistically control with a little effort.=C2=A0 How many fly-by-nigh= t BitTorrent clients are there out there?=C2=A0 The protocol is increasingl= y used in game updater-launchers, too.

- Jonathan Morton

--001a113b14e8504e8b0531c9d825--