General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Remarkably simple bloat managing use by a UK ISP
Date: Fri, 5 Jun 2015 19:39:45 +0200	[thread overview]
Message-ID: <CAC13B00-3A79-4C19-9375-D41B2C996460@gmx.de> (raw)
In-Reply-To: <CAA93jw7JSbNR-1f6AdLdYYmQerjyjFODxPi3M+zzRMuO4S6Nug@mail.gmail.com>

Hi Dave, hi LIst,

On Jun 5, 2015, at 18:46 , Dave Taht <dave.taht@gmail.com> wrote:

> On Fri, Jun 5, 2015 at 9:35 AM, Jonathan Morton <chromatix99@gmail.com> 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).
>> 
>> 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.
>> 
>> 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.
> 
> 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”. 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)
> 
>> 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.
> 
> 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.
> 
>> 
>> 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.
> 
> Yep. A godawful amount of thought and data went into all this...
> 
> ... and I stress in
> http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die
> 
> 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
> 
> https://www.youtube.com/watch?v=M1ONXea0mXg
> 
> (or something like that)
> 
>> - Jonathan Morton
>> 
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>> 
> 
> 
> 
> -- 
> Dave Täht
> 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


      parent reply	other threads:[~2015-06-05 17:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 14:46 Kevin Darbyshire-Bryant
2015-06-05 15:50 ` Dave Taht
2015-06-05 16:35 ` Jonathan Morton
2015-06-05 16:46   ` Dave Taht
2015-06-05 16:59     ` Jonathan Morton
2015-06-05 17:39     ` Sebastian Moeller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC13B00-3A79-4C19-9375-D41B2C996460@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox