From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D547F21F600 for ; Fri, 5 Jun 2015 09:46:39 -0700 (PDT) Received: by obbqz1 with SMTP id qz1so40421106obb.3 for ; Fri, 05 Jun 2015 09:46:38 -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:content-type:content-transfer-encoding; bh=TiDXIUMAtsej5xwDgP50mZJcWCHXOd6PaaRwgfzdJZA=; b=rNbwL6v2s7ssT1PyJ6CbE06m4afC/SBmXJ222UBGGqniF8CflIKAO20ss/P0UkTCOR qGmZTTkxTczSY4rOYsRCUlraGf0TE12vDmeT/6a9wwinfpum3VCQyL7ACOeqpto2wMf2 OIRKTbgOaU9rckxaT40toreHStIDzxb97f3Qv+mIljfzj4ehyPlXCuzlKFbi8JrEkKQ2 bjKBoGzb2EYOOk+ovY4LR6X/pMatxNhIdExX8G+K9gcbhj3hr5el/XVfueZIy6yn04Pc QurMzHYBwgYncPwDkVEhgtE4L/li4sOzFJ8y66/5iKp7hF4D6J5QQfTj8qdQPR29HxKE eUug== MIME-Version: 1.0 X-Received: by 10.202.91.212 with SMTP id p203mr3491393oib.108.1433522798817; Fri, 05 Jun 2015 09:46:38 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Fri, 5 Jun 2015 09:46:38 -0700 (PDT) In-Reply-To: References: <5571B636.8050908@darbyshire-bryant.me.uk> Date: Fri, 5 Jun 2015 09:46:38 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 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 16:47:08 -0000 On Fri, Jun 5, 2015 at 9:35 AM, Jonathan Morton wro= te: > Going back to fundamentals, there's a clear distinction between traffic > which is latency sensitive and traffic which is bandwidth sensitive. Perh= aps > 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 i= t, > especially since they managed to leave out such a common protocol as DNS. > > Packet size is a better heuristic than port number. Most latency sensitiv= e > protocols do tend to use small packets, and nearly all bandwidth sensitiv= e > traffic uses the largest packets it can. SSH also naturally switches betw= een > small and large packets depending on the type of traffic it's carrying. I= f > 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. 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 pack= ets > below the threshold if there is one, or slightly smaller than the competi= ng > traffic if there isn't one. The receiver can influence this by setting th= e > 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 ne= w > 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=3DM1ONXea0mXg (or something like that) > - Jonathan Morton > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast