From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EB7733CB37 for ; Thu, 14 Feb 2019 06:15:39 -0500 (EST) Received: by mail-ed1-f45.google.com with SMTP id b3so4718193ede.1 for ; Thu, 14 Feb 2019 03:15:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=IcZUeBu5zoD+9X7Mz3YplQ+8ITSvgOMRGy1DzX/aVVg=; b=fFJ7qEp1zPnhtib6v0H1oInXNLNO6GBWrbT89JJBKNnkpEPYEfA+GHWJZ1GGfeagzt GfwlAOfKGZWE3uzrwxLRv4/CxZvwMP2Co/z/8jnpnVGTWsTA/YH55244vHJbSJyE4aYy D9ms9hkQJ+tG0YLn1IrYxyvcs7XeV6qb1DRd2H2xkVQqeQ0YgpCFvx4f3WAAlEj7zOro y34YuESfA8fA/iJ8k4B0k7zpa+iad2yRdd/32CDDHf5AukZkcYxvJP7l7zfsPgW4cQ71 OWbVgqKsHpve42n/d+KT1BxG1FXYCFaTFlD0gV1A4qabyTluF5An/OOkJlOS6n+nefGM K2dQ== X-Gm-Message-State: AHQUAuYOFTGlHFkclYYN0MIupxx6rtYMtKQKaAsWtbDpVHNStwynu/nu F1t5nkUefVI7hqqOOTZDTB74Qw== X-Google-Smtp-Source: AHgI3IYEz4com4ABwUlLxUKt702s8E/YIGGxQxJJp2NVCfeNXns430VCLyOMiPU1muW14L3FaIIkHg== X-Received: by 2002:a50:a4ec:: with SMTP id x41mr2685227edb.174.1550142939006; Thu, 14 Feb 2019 03:15:39 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id m13sm608149edd.2.2019.02.14.03.15.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Feb 2019 03:15:37 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 3287A1825D3; Thu, 14 Feb 2019 12:15:37 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: gamanakis@gmail.com, 'Jonathan Morton' Cc: cake@lists.bufferbloat.net In-Reply-To: <000001d4c3d3$54d46b30$fe7d4190$@gmail.com> References: <20190213183132.11019-1-gamanakis@gmail.com> <144BF042-D64B-45D2-BF48-16FD7AE67411@gmail.com> <006b01d4c3d2$090c3350$1b2499f0$@gmail.com> <000001d4c3d3$54d46b30$fe7d4190$@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 14 Feb 2019 12:15:37 +0100 Message-ID: <87a7iymxie.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] progress? dual-src/dsthost unfairness X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 11:15:40 -0000 gamanakis@gmail.com writes: >> On the contrary, even if a particular flow is sparse, the relevant >> quantum calculation should involve the number of *bulk* flows >> attached to the same host. Though there is possibly an argument for >> making it the *sum* of the sparse and bulk flows, making it just the >> sparse ones is wrong. > > I was about to point out that my assumption is obviously wrong. > cake_enqueue() can still assign a packet to a bulk flow. Will try with > the sum of the flows and report. >From a fairness perspective it doesn't really matter whether you count the sparse flows or not. You use this for assigning a single quantum's worth of initial deficit; any flow that actually needs fairness enforced is going to be backlogged anyway, and the deficit increase in bulk state is what matters for enforcing fairness. What the initial quantum does is that it limits how big packet(s) a sparse flow can send before it is demoted to bulk. There are certainly some esoteric cases where this might matter (things like, can a DNS flow get two small back-to-back packets through in one go); but this is going to vary with the traffic conditions anyway, so I doubt it matters in practice. Given this, and given that the state tracking is already plenty complicated, I'd suggest not counting per-host sparse flows at all, and just using the bulk count. I'm pretty sure you'll get the same fairness behaviour in this case. Care to try that? :) -Toke