From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0101421F621 for ; Fri, 5 Jun 2015 10:39:47 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.71.188]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M70HF-1ZEizV2Vgz-00wiem; Fri, 05 Jun 2015 19:39:44 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 5 Jun 2015 19:39:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5571B636.8050908@darbyshire-bryant.me.uk> To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:iUH7ZkVReaq9gAJJNzUMmijKO0irGtMk9M3DLzQfOvYQ13nJYDG f4eDLZP6U/FjQkVC0WZp1Gfx0Q8d9K1IJrzAheMU4yFwBl58Z5b7ojwtWd651hplCbywue6 kor6bJTP6nr+ScKZdPBRbw5ChvhAwn7oMWOgIw3M11EgU1sinqnuuOZOaxe9XHyaMsdr7f3 FHDneL2ECI2cHLhaX5jCQ== X-UI-Out-Filterresults: notjunk:1; Cc: Jonathan Morton , bloat Subject: Re: [Bloat] Remarkably simple bloat managing use by a UK ISP X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:40:16 -0000 Hi Dave, hi LIst, On Jun 5, 2015, at 18:46 , Dave Taht wrote: > On Fri, Jun 5, 2015 at 9:35 AM, Jonathan Morton = wrote: >> Going back to fundamentals, there's a clear distinction between = traffic >> which is latency sensitive and traffic which is bandwidth sensitive. = Perhaps >> surprisingly, web traffic tends to fall into the former category, = unless the >> link bandwidth is very low by current standards (analogue modem = territory). >>=20 >> It sounds like that router's default settings attempt to make that >> distinction based on port number, and then perform strict = prioritization. >> The example of SSH demonstrates why that doesn't work; interactive = shell >> over SSH is latency sensitive, but SCP and rsync-over-SSH are = bandwidth >> sensitive, and they all use the same port. The need for explicit >> configuration (a database of port numbers) is also a black mark = against it, >> especially since they managed to leave out such a common protocol as = DNS. >>=20 >> Packet size is a better heuristic than port number. Most latency = sensitive >> protocols do tend to use small packets, and nearly all bandwidth = sensitive >> traffic uses the largest packets it can. SSH also naturally switches = between >> small and large packets depending on the type of traffic it's = carrying. If >> you simply sort your traffic by packet size, you don't even need to >> configure it - but otherwise you just have a threshold to set and = forget. >> Cunningly, this also naturally performs ack and ping promotion. >=20 > I do not regard ping promotion as a "feature". I think ping should be > a measurement of worser-case latency. I would be most happy with a measurement probe that reflects how = the network treats the traffic characteristics currently tested. Now, = pings typically are both small and sparse, so both sparse fq-ing and = small size priority will treat pings with "loving care=94. Changing the = packet size with ping is easy if one wants to test how larger packets = traverse the network. Making ping non-sparse is a bit more involved as = the ping binary somehow thinks that non-root should be throttled to 5 = pings per second I believe (which on a a beefy desktop system is easily = worked around by starting independent ping instances by hand, but I = digress). Best Regards Sebastian > Openwrt does both synflood and > ping flood protection in their firewall implementation badly with a > fixed limit too low for synflood (it used to be 25/sec), and too high > for ping flood.(1000/sec and extensive filtering) >=20 >> The downside of packet size as a heuristic is that it's possible to = game it, >> especially with strict priority in force. All you have to do is send = packets >> below the threshold if there is one, or slightly smaller than the = competing >> traffic if there isn't one. The receiver can influence this by = setting the >> MSS low during TCP handshakes. >=20 > There is a natural game theory influence pushing packet size larger > for bulkier traffic, and that is header overhead gets pretty > significant as you get below 300 bytes. >=20 >>=20 >> That is why fq_codel uses the sparse/saturating flow distinction for >> priority. It's a much more robust heuristic than packet size, = requires no >> configuration at all, and is not so easy to game. The downside? It's = only >> available if you're already doing flow isolation, which basically = solves the >> core problem on its own. Still, making that distinction does help = with new >> flow startup and jitter reduction. >=20 > Yep. A godawful amount of thought and data went into all this... >=20 > ... and I stress in > http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die >=20 > that in 10 years someone might be cursing us for using any of these > techniques so universally because it interacts badly with the latest > brain to network direct connect with high speed voice response >=20 > https://www.youtube.com/watch?v=3DM1ONXea0mXg >=20 > (or something like that) >=20 >> - Jonathan Morton >>=20 >>=20 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht > What will it take to vastly improve wifi for everyone? > https://plus.google.com/u/0/explore/makewififast > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat