From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 53FF121F5E4 for ; Fri, 5 Jun 2015 08:50:44 -0700 (PDT) Received: by obcej4 with SMTP id ej4so6102314obc.0 for ; Fri, 05 Jun 2015 08:50:44 -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=A7y0jTE6AcLz19TwmSoBnR6USby7cdcx/PM0G644wic=; b=En6wVt07cVgGyBYIHTaB6ximY1Tzp7Ng/Kn9TG8St/a/xor9i2NjlAhYl1iTDEQGBm W5cMGNNpbbGvH2gBUrMNohYCC0Po/PfEvQYdK6xQjcrMH/vLIOMmqt3sLmeYIGIwqDfq 9cbm7FrleZueVJJEcxJim9mxIsc0h8VH2mcKeDhHjWQrHhJtwD4nPRh+mOuIDS29zXz/ 24xOSwzOLcgGbe2OolQsSCYCyMYcESSJQnSNmefJRBSNtWOdEslU44be3HPtfVMHl7uV R/PVhu6MID300TBsg59BMI4o7Dz2vJZFP/uy6Mh0vRfPmDYg1S458NB2es1UaaA3d1C5 hWTw== MIME-Version: 1.0 X-Received: by 10.202.91.212 with SMTP id p203mr3291423oib.108.1433519444002; Fri, 05 Jun 2015 08:50:44 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Fri, 5 Jun 2015 08:50:43 -0700 (PDT) In-Reply-To: <5571B636.8050908@darbyshire-bryant.me.uk> References: <5571B636.8050908@darbyshire-bryant.me.uk> Date: Fri, 5 Jun 2015 08:50:43 -0700 Message-ID: From: Dave Taht To: Kevin Darbyshire-Bryant 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 15:51:13 -0000 Yes, making a distinction between large and small packet sizes helps. There is a clear bifurcation in network traffic at around 300 bytes, with all kinds of packet sizes below 300, with very few packets sized in the 300-1100 byte range. webrtc and hangout traffic tends to about 1000 bytes for some reason. As shipped in openwrt and the sqm-scripts, 300 is the default fq_codel quan= tum. Along the way we explored per packet fairness not just with SFQ but fiddling with the drr (and later, fq_codel) quantum, settling initially on 500 bytes and after much testing, we cut to 300 bytes. There was a variant (pfq_codel I think it was in the codebase) that attempted per packet against all small flows fairness (fiddling with the new/old queue concept) - but it did badly. I think nfq_codel still exists in cerowrt as it did quite well also (I can no longer remember what it did, but it also served more different flows within a quantum). It is kind of unclear, scheduling for higher bandwidths (100s of mbits), what the drr quantum should be. Cake is experimenting with gradually increasing the quantum as bandwidths grow. I lean towards sticking with 300 bytes until you crack a gigabit. sch_fq (targetted at 10gigE+) defaults to 2 packets (3018) which has the nice property of releasing a delayed-ack on the other side. (I had talked to john nagle a long time ago and one of the things he sighed about was that he was deeply unhappy (starting in 198x!) about the delayed ack concept, but he never explained why, and I have assumed it was the loose interaction with fq... and lets not go into stretch acks!) It had been my hope that the new/old flow distinction in fq_codel at the default packet quantum (1514) would provide a useful signal to a tcp type about the actual path RTT, but I think (now, 3 years later), that gets smoothed away. Still, the new paced stuff (which can measures the baseline RTT from the syn/synack pair) interacts nicely with the new/old distinction in fq_codel at 300 bytes. To mess up this observable portion of the universe and "easy fix", there are tcp fast open and quic. On Fri, Jun 5, 2015 at 7:46 AM, Kevin Darbyshire-Bryant wrote: > Hi Chaps, > > I was speaking with Andrews & Arnold (a UK clueful ISP) about their > experiences with bufferbloat and was sent this graph: > https://support.aa.net.uk/VMG1312:_QoS > > I was surprised at how such a simple 'priority by packet size' scheme > appears to work. Clearly there's slightly more going on in that the box = in > question *knows* the outbound bandwidth and doesn't let a standing queue > form...but priority by packet size? Hmm. > > Kevin > > > _______________________________________________ > 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