From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 264163B2A4 for ; Thu, 16 Nov 2017 01:52:40 -0500 (EST) Received: by mail-qt0-x22f.google.com with SMTP id u42so17320121qte.7 for ; Wed, 15 Nov 2017 22:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=25mJue3NtA2mD1VbGhxI+xABJaUOTC56I+NrszGrwH8=; b=A3Zbdw3xMwE0yNJTmq/6uDpmEnXdzh54NHGmLMlzdy2ikpZpu5ikEqkYNBj86peIEQ 30wkypthOYXffXFyVlZfOchzD+0PDqNC2UWk5GGJkv9gTDjsfOPBXkSq+y/Z4/0/83VE XiA4HSLBOemfhxP/gF0J4W2OLnhT8t6usLmYx8tZ0mCt92QHfgyE9pFxmrs/oDmes3u4 aUSBPptG6ytiFmWSCilKqcorKqTx+GMa8BfTkGzEyb4YvGF3O79YKqSbG6ey04UJLox6 OVEA8eVeUL62JwH9LkBNMnzDM5pYVQhcV+K4+2p+A4gPqyDpqjIOabTkgp3aJSfgI8OR lyIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=25mJue3NtA2mD1VbGhxI+xABJaUOTC56I+NrszGrwH8=; b=qtNENVei5d5jfkZIHwQ4++R7U4oLzy0qpTJn8YJvFhm47TxFyCUFKDqj9NOwnbf2k+ 0cf0IcsCEydd66p5hiXlWi86Hf/H4zPciMAESUmM5y1enQt3mt2s7qkzRtV/FHBT/j7f ciqA1HkhyUSW0V3aNZlCk3r6HnjEIge7NJhlgxpzbt4TAPuq+wvXGQXchNTlv7qkOSNn 8ksWRnd5lIcdoumTlhC7u79uRvYruJQUzGnIga+pHEhgbO9SufPBA4JOYhecrU6lNWN9 c7Egzex4/zHGr5v1pjTYgl5q2KJ2EzKgcQ338Iwh1hJ4706oeizwWIQy4/KTzQxtdatR +iOQ== X-Gm-Message-State: AJaThX6nfA59b1rdAGub4voVRvdGKuVRGXPF8sFISsAlobl9DMEzZ72n oDYKNrk5i1oC1KsaUpMpXDtIIZzgYU/DM4CvODg= X-Google-Smtp-Source: AGs4zMa9f3ceS/ePqlSp5JOlNkr7Vu7XWTo5nwI9p66/rXJ3pMJZj7fdUBGFjGoY4Z6agYmJmJ6dJWc7QCllYeYH50o= X-Received: by 10.55.72.75 with SMTP id v72mr946716qka.92.1510815159775; Wed, 15 Nov 2017 22:52:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.80.133 with HTTP; Wed, 15 Nov 2017 22:52:39 -0800 (PST) Received: by 10.140.80.133 with HTTP; Wed, 15 Nov 2017 22:52:39 -0800 (PST) In-Reply-To: References: <87po92aku1.fsf@nemesis.taht.net> <87efph4q0y.fsf@nemesis.taht.net> <87vaihkgr9.fsf@nemesis.taht.net> <87r2t08vtz.fsf@nemesis.taht.net> <91059e40-31fa-b2a7-dced-0f0bd17ba853@yahoo.com> From: Jonathan Morton Date: Thu, 16 Nov 2017 08:52:39 +0200 Message-ID: To: Dave Taht Cc: George Amanakis , Cake List Content-Type: multipart/alternative; boundary="001a114a7b86eb79b2055e14105a" Subject: Re: [Cake] total download rate with many flows 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, 16 Nov 2017 06:52:40 -0000 --001a114a7b86eb79b2055e14105a Content-Type: text/plain; charset="UTF-8" I'm curious as to why you think Cobalt is more aggressive than Codel. It does use more accurate approximations to the mathematical ideal than the "reference" codel does. It is however very odd that the Diffserv mode has any effect on this at all. It could be explained if a lot of the traffic is marked CS1, since the Bulk tin has looser AQM parameters. That suggests that selecting 'satellite' might help similarly. Something worth trying would be to alter the failsafe shaper's rate of advance. Currently it has a one-quarter rate, which might be too restrictive. Tests at one-half and three-quarters might therefore be interesting. Otherwise, I don't think trying to modify the way ingress mode works will do the right things. Ultimately, this arises because Cake is having to drop packets in order to signal congestion, and when there's a lot of flows, a lot of signals must be sent to get through to them all. With ECN working, it doesn't need to waste bandwidth merely to signal. The only other reasonable approach is to somehow reduce the signalling rate under heavy flow load. That requires informing Cobalt of the number of bulk flows, and using that to scale the signalling frequency somehow. - Jonathan Morton --001a114a7b86eb79b2055e14105a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm curious as to why you think Cobalt is more aggressiv= e than Codel.=C2=A0 It does use more accurate approximations to the mathema= tical ideal than the "reference" codel does.

It is however very odd that the Diffserv mode has any effect= on this at all.=C2=A0 It could be explained if a lot of the traffic is mar= ked CS1, since the Bulk tin has looser AQM parameters.=C2=A0 That suggests = that selecting 'satellite' might help similarly.

Something worth trying would be to alter the failsafe shaper= 's rate of advance.=C2=A0 Currently it has a one-quarter rate, which mi= ght be too restrictive.=C2=A0 Tests at one-half and three-quarters might th= erefore be interesting.=C2=A0 Otherwise, I don't think trying to modify= the way ingress mode works will do the right things.

Ultimately, this arises because Cake is having to drop packe= ts in order to signal congestion, and when there's a lot of flows, a lo= t of signals must be sent to get through to them all.=C2=A0 With ECN workin= g, it doesn't need to waste bandwidth merely to signal.

The only other reasonable approach is to somehow reduce the = signalling rate under heavy flow load.=C2=A0 That requires informing Cobalt= of the number of bulk flows, and using that to scale the signalling freque= ncy somehow.

- Jonathan Morton

--001a114a7b86eb79b2055e14105a--