From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5D2C6200685 for ; Wed, 4 Jan 2012 09:36:33 -0800 (PST) Received: by vbbfq11 with SMTP id fq11so24524023vbb.16 for ; Wed, 04 Jan 2012 09:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rl1Mu8OcZyxT8v4YxK5wh3AuBmRMCkKgjwBVg1EqvkU=; b=j3vBwcal8mJPKtIi23Oc9h2NudV/k7+QkwgGb2wRQ+TmatTLQ4s2CBPK9GdTmSRJhr foPlDP5RIMGh84zPGhiouv4GU2FcwuY9rj/WH4rP+5kICvRcLgxT97YlZq27LsnUx0p6 OSiAD6qG1eFp57bUTn6WA+rJQqIPZK82JSyKE= MIME-Version: 1.0 Received: by 10.52.240.226 with SMTP id wd2mr27871731vdc.50.1325698592060; Wed, 04 Jan 2012 09:36:32 -0800 (PST) Received: by 10.52.155.98 with HTTP; Wed, 4 Jan 2012 09:36:31 -0800 (PST) In-Reply-To: References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> Date: Wed, 4 Jan 2012 12:36:31 -0500 Message-ID: From: Justin McCann To: Dave Taht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired! 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: Wed, 04 Jan 2012 17:36:33 -0000 On Wed, Jan 4, 2012 at 11:16 AM, Dave Taht wrote: > > On Wed, Jan 4, 2012 at 4:25 PM, Jim Gettys wrote: > > > =A0 =A01) since TCP is not "fair", particularly when given flows of > > different RTT's, how do we best deal with this issue? =A0Do either/both > > SFQ/QFQ deal with this problem, and how do they differ? > > The reason why QFQ was outperforming SFQ here > > http://www.teklibre.com/~d/bloat/pfifo_sfq_vs_qfq_linear50.png > > was because SFQ was =A0enqueuing the first packet of a new stream at the > end of the existing streams. > > After eric moved the SFQ enqueue to head, the two started performing > the same at light workloads. > > (keep in mind the comparison already to pfifo_fast - log scale) > > http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.png > > So, the net effect of either fq mechanism is that slower flows jump > forward in the queue. > RTT =A0is not really relevant. [1] I must have misinterpreted the 'new flows' discussion on netdev. Are these new flows in the sense of SYN/SYN-ACK, or new flows in the sense of "don't have any packets in the queue(s) right now"? > 1: the 'slower flows gain priority' question is my gravest concern > (eg, ledbat, bittorrent). It's fixable with per-host FQ. Meaning that you don't want to hand priority to stuff that is intended to stay in the background? How does the classification work you've been doing interact with these latest QFQ tests? Justin