From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (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 4491221F5F5 for ; Fri, 5 Jun 2015 09:35:04 -0700 (PDT) Received: by vnbf1 with SMTP id f1so9725960vnb.6 for ; Fri, 05 Jun 2015 09:35:03 -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; bh=Ks55mrONAJ/QxNWnebjClagDxlCmDqEqtEjXDaguwY4=; b=mHHNpuCb4sfnoTpURbBgv8RlIPFJBlRZKV6wyZ0+nfkAM5L6k2KrqnDxNWkNPbD+P9 LIYodstufRPX2inInYY9H+ZKlWWOddiH+RPB6PW8i/eW8fziJYobUZvQm81TKtbSmxXw hBsoSnQ+Qim6ICrxaH24eD7HB+3RgFRF0nmEWcRG/3ObjQlbMuHtGN4Pn/6uBlfcVEWY 88cso+Pzg4jpn5oArNDRYvBihnj834MtsE1jh51FgTSBwDZHSNlK0hU3DqmuNEi9od/m KmfUEpyYpETbxg/8nFl4TOb5ZvoXaL2zyEWwl7F8Ka+ruWCs2OLAAjfbDRI2LX9SRsSH ADPw== MIME-Version: 1.0 X-Received: by 10.52.178.5 with SMTP id cu5mr7656795vdc.20.1433522103590; Fri, 05 Jun 2015 09:35:03 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 5 Jun 2015 09:35:03 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Fri, 5 Jun 2015 09:35:03 -0700 (PDT) In-Reply-To: <5571B636.8050908@darbyshire-bryant.me.uk> References: <5571B636.8050908@darbyshire-bryant.me.uk> Date: Fri, 5 Jun 2015 19:35:03 +0300 Message-ID: From: Jonathan Morton To: Kevin Darbyshire-Bryant Content-Type: multipart/alternative; boundary=bcaec5016137c3268c0517c7df1a 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:35:33 -0000 --bcaec5016137c3268c0517c7df1a Content-Type: text/plain; charset=UTF-8 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. 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. 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. - Jonathan Morton --bcaec5016137c3268c0517c7df1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Going back to fundamentals, there's a clear distinction = between traffic which is latency sensitive and traffic which is bandwidth s= ensitive. Perhaps surprisingly, web traffic tends to fall into the former c= ategory, unless the link bandwidth is very low by current standards (analog= ue modem territory).

It sounds like that router's default settings attempt to= make that distinction based on port number, and then perform strict priori= tization. The example of SSH demonstrates why that doesn't work; intera= ctive shell over SSH is latency sensitive, but SCP and rsync-over-SSH are b= andwidth sensitive, and they all use the same port. The need for explicit c= onfiguration (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 lat= ency sensitive protocols do tend to use small packets, and nearly all bandw= idth sensitive traffic uses the largest packets it can. SSH also naturally = switches between small and large packets depending on the type of traffic i= t's carrying. If you simply sort your traffic by packet size, you don&#= 39;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 promo= tion.

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 sma= ller than the competing traffic if there isn't one. The receiver can in= fluence this by setting the MSS low during TCP handshakes.

That is why fq_codel uses the sparse/saturating flow distinc= tion 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 distinctio= n does help with new flow startup and jitter reduction.

- Jonathan Morton

--bcaec5016137c3268c0517c7df1a--